|
WM_QUIT[^] WM_DESTROY[^] WM_CLOSE[^]
xqhrs232 wrote: which order is excuted?
"You can use the DestroyWindow function to destroy a window. Typically, an application sends the WM_CLOSE message before destroying a window, giving the window the opportunity to prompt the user for confirmation before the window is destroyed" from msdn
so normally First WM_CLOSE, then default handler calls DestroyWindow which sends WM_DESTROY, WM_DESTROY handler typically calls PostQuitMessage which sends WM_QUIT to terminate the message loop.
|
|
|
|
|
Why not set a breakpoint in each one, or add some sort of debug/trace message to find out?
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
My thoughts exactly. Not only is it more satisfying to figure things out for yourself, it also usually provides a better understanding of the problem/solution.
Nowadays people seem to prefer spamming the message boards with trivial questions...
"It is better to remain silent and be thought a fool, than to open your mouth and remove all doubt."
--Groucho Marx
|
|
|
|
|
Michael Schubert wrote: "It is better to remain silent and be thought a fool, than to open your mouth and remove all doubt."
--Groucho Marx
This same quote has been attributed to Abraham Lincoln, Mark Twain, and Benjamin Franklin.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Damn, should have done some research before...
"It is better to remain silent and be thought a fool, than to open your mouth and remove all doubt."
--Groucho Marx
|
|
|
|
|
That is what I made when I started with MFC, open the assistant in an empty programm and put AfxMessagesBox'es to see the order. To see the order it is ok, but to see/understand relationships and so on... a little google / articles research is needed. People sometimes is just lazy.
Greetings.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
|
|
|
|
|
You use WM_CLOSE to ask a window to close itself. This gives it a chance to ask the user whether to save documents, etc. The default handling (by DefWindowProc) is to call DestroyWindow.
You never send WM_DESTROY yourself. It is sent to the window by the DestroyWindow function to allow it to do some final cleanup.
On desktop Windows (i.e. not on Windows CE) there is also a WM_NCDESTROY message which is sent after WM_DESTROY, when the non-client area is destroyed. This will be the last message ever for that window and can be handled for final final cleanup
WM_QUIT isn't really a window message at all. It's a status flag in the message queue which is set when PostQuitMessage has been called. You should never send WM_QUIT. Its sole purpose is to get GetMessage to return 0. Once the quit message has been retrieved the status flag is cleared, so if you've created a nested message loop you should call PostQuitMessage again to cause the next message loop in the chain to quit as well. MFC and ATL call PostQuitMessage after handling WM_NCDESTROY on the thread's main window (that pointed to by CWinThread::m_pMainWnd in the case of MFC). See Raymond Chen's blog entries on WM_QUIT[^] and PostQuitMessage[^].
If you're coding it yourself using just the Win32 SDK, you normally call PostQuitMessage in response to receiving a WM_DESTROY message. You only have to handle WM_CLOSE yourself if you want to interrupt and potentially prevent the window from closing, as long as you're passing everything you don't handle down to DefWindowProc. (No, really, you need to pass all unhandled messages to DefWindowProc[^].)
DoEvents: Generating unexpected recursion since 1991
|
|
|
|
|
How do I insert my own entry in Windows Security Center for AntiVirus, AntiSpyware and firewall using WMI ?
Kind Regards
Manoj Jangid
|
|
|
|
|
hi 
i am uing copyfile(source,destination,ifoverwrite).from the main application
i am passing the source and the destination path and coping the required file(image) to temp folder and processing it.
the copy file sometimes fails.can any one help me on this issue.
here niether the source nor the destination file is used by my main application.
Thanks in advance
|
|
|
|
|
Do you know about GetLastError?
BTW third parameter should be FALSE in order to overwrite an existing file.
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
|
|
|
|
|
Did you try with SHFileOperation?
|
|
|
|
|
Hi All,
I am trying to use the API CreateProcessWithLogonW in my app. I get an error message which says "The specified service does not exist as an installed service" with error code 1060. Does anyone has any idea why this is happenning?
Thank you,
AJ
|
|
|
|
|
which OS you are working on, Check whether the RunAs service is started; on Windows XP it is named "Secondary Logon service, possibly for security reason, this service may be disabled in your machine(by admin), check the runas command also.
|
|
|
|
|
Thanks a lot!! I was running it on XP Embedded. That explains why it isn't running!
Thanks again,
AJ
|
|
|
|
|
|
I would like to know the reason why this post is voted down.
|
|
|
|
|
I don't know who has voted down...and how do you vote?
|
|
|
|
|
|
|
Can the performance of this API be improved in any way? I tried out the API and it is way too slow. I guess this might be because of the fact that it has to logon with the credentials that I provide and then launch the process.
|
|
|
|
|
HHOOK SetWindowsHookEx(
int idHook, // type of hook to install
HOOKPROC lpfn, // address of hook procedure
HINSTANCE hMod, // handle to application instance
DWORD dwThreadId // identity of thread to install hook for
);
The fourth parameter is a thread id,not a process id.
While I give it explorer.exe's process id ,the function can't succeed.
How can I do?
In DLL and use Detours.
Science is a forever enigmatic modified on Friday, April 25, 2008 3:34 AM
|
|
|
|
|
Hi,
dwThreadId Specifies the identifier of the thread with which the hook procedure is to be associated.U cannot give processid in place of thread.
A process can have only one process id. In a process is a main thread and one or more child threads. So both are different.If you want to hook Explorer window set the threadId(in SetWindowsHook) to 0 then in HookProc check the class name of the Window and if it is "CabinetWClass" using GetClassName API and hook it.
thanks
Nitheesh
|
|
|
|
|
Thank you very match.
I will try an experiment on it with you said.
But how to get a main thread id with process id?
modified on Sunday, April 27, 2008 9:03 PM
|
|
|
|
|
Hi,
use GetWindowThreadProcessId to get the id of the Thread
thanks,
Nitheesh
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
