|
Check this link->[^]
I believe in LOVE AT FIRST SITE...
Bcoz I have loved my Mother...
even since I opened my eyes...(ICAN)
|
|
|
|
|
Isn't imlSortStates going out of scope? I would make that object a member of the dialog.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I use the Shell_NotifyIcon(NIM_ADD, &m_nidIconData) to add a tray icon for my application. The Icon is added. but when Mouse moved over this icon, the icon disappear. Is there any other statements needed to write?
modified on Monday, January 24, 2011 9:33 PM
|
|
|
|
|
Sounds like the application that installed the icon is no longer running and didn't remove the icon. Explorer realises something's wrong when you interact with the icon and it attempts to communicate with the controlling procress (and fails).
Steve
|
|
|
|
|
Is your application running ? Make sure that your application is running when icon disappears.
|
|
|
|
|
Yes, My application is running when tray icon appear and disappear.
|
|
|
|
|
OK, so you say the process that installed the icon (by calling <a href="http://msdn.microsoft.com/en-us/library/bb762159%28v=vs.85%29.aspx">Shell_NotifyIcon</a>[<a href="http://msdn.microsoft.com/en-us/library/bb762159%28v=vs.85%29.aspx" target="_blank" title="New Window">^</a>]) is still running. This would suggest that the window handle (the hWnd member of the NOTIFYICONDATA[^] structure) you passed when adding it is no longer valid (the window has been destroyed).
Steve
|
|
|
|
|
Right. I agree with Stephen. Please check with the window which registered for tray icon. As notification goes to that window, if the window doesn't exists the notification icon also will be removed.
|
|
|
|
|
|
This problem resolved. I set the wrong parameters to the m_nidIconData. One parameter needed to set the hWnd of Dialog. But I didnot set it.
Thanks for your reply.
|
|
|
|
|
i have a code from one of my past papers n it was asked to put the reason that what was wrong with that code. i looked on it very much but didnt find any problem. following is the code, kindly tell me even if there is any efficiency or any other drawback in this code.
class A {
int *pi;
public:
A() { pi = new int; }
};
|
|
|
|
|
int *pi; instead of int* pi;
{ pi = new int; } no parentheses, no return.
Short meaningless names? Unaligned braces? Not enough whitespace? No pre tags? I dunno.
|
|
|
|
|
You never delete the memory allocated with new.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
1) Add a destructor
~A() { delete pi; }
2) Either
A) Initialize the pointer to 0 first
A()
:pi(0) {
pi=new int;
}
B) Initialize the pointer (preferred in this case since it is highly unlikely the memory allocation will fail)
A()
:pi(new int) {}
|
|
|
|
|
My original comment was misplaced.
I suspect that the real problem may be that the variable pi is private and thus can never be accessed outside the class. So creating an object of class A serves no real purpose as you cannot set or get the value of pi.
I must get a clever new signature for 2011.
modified on Sunday, January 23, 2011 8:32 AM
|
|
|
|
|
Aside from the fact that the code doesn't do anything useful, the really serious problems with this class are:
- It will leak in normal operation (I use the term "operation" loosely here as the class doesn't do anything)
- It isn't exception safe or neutral
To fix these you're going to need a destructor, a copy constructor (or a private declaration of a copy constructor) and a swapping assignment operator (or a private declaration of an assignment operator).
In addition (ignoring the questionable sanity of storing an int like that) the implementation could be tightened up to use an initialiser list.
The idea here is to make a class that behaves like a object of a type built into the language. The structure your class needs to achieve this is known in some circles as "The Orthodox Canonical Form" and the first place I saw it mentioned and explained properly was in "Advanced C++: Programming Styles and Idioms" By Jim Coplien back in the early 90s. Other authors have picked up the term since then so a search for it might give you some more background.
Cheers,
Ash
|
|
|
|
|
I support this answer, this is more reasonable.
Величие не Бога может быть недооценена.
|
|
|
|
|
Oh, sure, if you want to get all technical. 
|
|
|
|
|
Building on some of the already posed answers:
As mentioned before, you need a destructor to make sure pi is released.
Moreover, if you provide no Copy constructor or assignment operator, the compiler will create these for you. Both will simply copy pi over without checking, und thus also produce a memory leak. This means you need to define both a copy constructor and an assignment operator yourself, to prevent memory leaks from inadvertent copying!
Another, minor, issue is that you didn't think to initialize the integer pi is pointing to.
I will ignore the apparent uselessness of the class in it's current state, assuming that it's going to be expanded later. Going with the above, I would rewrite this to sth like that:
class A {
int* pi;
public:
int* getpi() {
if (0 == pi)
pi = new int();
if (pi != 0)
*pi = 0;
return pi;
}
A() : pi(0) {}
A(const A& other) : pi(0) {
*getpi() = *other.pi;
}
~A() { delete pi; }
A& operator=(const A& other) {
*getpi() = *other.pi;
return *this;
}
}
Note that you could also implement a shallow copy by just redirecting pi to wherever the other object's pi is pointing, but if you do that, you need some mechanism such as reference counting to prevent deleting an int object while oter instances are still pointing to it!
Note also that I only programmed the happy case with respect to allocation: if getpi() ever fails to allocate pi (and thus returns 0), then the call to the copy constructor or assignment operator will throw a NULL pointer exception. You might want to catch that, especially in the constructor.
[edit]Made getpi() public to resolve the inaccessibility issue, and added initializion of *pi[/edit]
modified on Monday, January 31, 2011 6:02 AM
|
|
|
|
|
I expect the standard specifies that whitespace within macro replacement text be reduced to a single space, but I am experimenting with something that requires otherwise.
Does anyone know of a C preprocessor with an option to retain whitespace within the replacement text?
After all, most will allow you to retain comments intact.
|
|
|
|
|
As far as I know, none do. And there is a reason for that. You don't need to, and it makes absolutely no difference to the code.
Quoted strings inside macros retain their white space, for obvious reasons.
What are you trying to achieve with this?
(Maintaining the # symbol would be pretty awesome tho)
EDIT: They maintain the fact that "there is white space there" because that often matters, but they don't necessarily remember how much
|
|
|
|
|
Andrew Brock wrote: there is a reason for that
Not a very compelling one, in my opinion.
Andrew Brock wrote: You don't need to
Ordinarily no, but ordinarily you don't need to include comments either, yet you can if you choose to.
Andrew Brock wrote: it makes absolutely no difference to the code.
It does to what I'm trying now.
Andrew Brock wrote: (Maintaining the # symbol would be pretty awesome tho)
That can be done with a second macro. I've done that for PRO*C, and in what I'm trying to do now.
# define __second_pass__ #
__second_pass__ include <stdio.h> /* This will get included on the second pass through the preprocessor, not the first */
But, what I'm trying to do now is have a macro produce a directive for the second pass, and for that I need linefeeds. It's really not worth the effort and only I would try, but as long as preprocessors allow retaining comments, why not also allow retaining whitespace in macroes?
|
|
|
|
|
PIEBALDconsult wrote: Not a very compelling one, in my opinion.
Macros exist to provide some specific functionality in C and C++. They don't exist to meet every possible known need. Myself I am comfortable with the notion that the authors of those languages and the numerous others who contributed to the ANSI specifications did in fact give due consideration to what it should do an what it shouldn't do. Given the extensive years of scrutiny and use that resulted from that I would suspect that your "compelling one" isn't very.
I am pretty sure that the creators of C and C++ were comfortable with the notion that if someone wanted to create their own language then they should in fact do exactly that.
And there are in fact other macro compilers. I suspect that the following provides quite a bit of functionality. And since one can in fact modify what it does you can do whatever you want with it.
http://www.gnu.org/software/m4/[^]
However, myself would not want to maintain code where someone thought that they needed to use clever tricks via the macro to achieve something. The vast majority of time clever tricks increase the cost of code maintenance.
|
|
|
|
|
jschell wrote: your "compelling one" isn't very.
I didn't say there was one.
jschell wrote: other macro compilers
I hadn't considered that, thanks.
jschell wrote: clever tricks increase the cost of code maintenance
Absolutely, and this is kinda to prove that point.
|
|
|
|
|
PIEBALDconsult wrote: I didn't say there was one.
I apologize. Your post is clear but somehow I managed to read something into it which wasn't there at all.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
