WM_CLOSE vs WM_DESTROY

[Don57]

I was reading the answers to RuiLoureiro post, by dedndave and qWord about using WM_DESTROY to close handles etc. I'm not sure if I've got it right. From what I gathered WM_DESTROY is used for cleanup and WM_CLOSE is used to close child windows. Don't child windows close automatically when the parent window is closed.

      .ELSEIF uMsg==WM_DESTROY
           
          INVOKE ReleaseDC, hGlobal_hWnd, hdc 
          INVOKE DeleteObject,hBrush1
          INVOKE HeapFree, hProcessHeap, 0, lp_HeapAlloc
          INVOKE DestroyWindow,hGlobal_hWnd
          INVOKE PostQuitMessage,NULL
          xor eax,eax
   

[jj2007]

WM_CLOSE allows you to decline shutdown, e.g. with a MsgBox "are you really sure?"

[RuiLoureiro]

I was reading the answers to RuiLoureiro post, by dedndave and qWord about using WM_DESTROY to close handles etc. I'm not sure if I've got it right. From what I gathered WM_DESTROY is used for cleanup and WM_CLOSE is used to close child windows. Don't child windows close automatically when the parent window is closed.

      .ELSEIF uMsg==WM_DESTROY
           
          INVOKE ReleaseDC, hGlobal_hWnd, hdc 
          INVOKE DeleteObject,hBrush1
          INVOKE HeapFree, hProcessHeap, 0, lp_HeapAlloc
          INVOKE DestroyWindow,hGlobal_hWnd
          INVOKE PostQuitMessage,NULL
          xor eax,eax

Yes it is exactly what i understood: when we get  WM_DESTROY
               we
                     INVOKE ReleaseDC, hGlobal_hWnd, hdc 
                     INVOKE DeleteObject,hBrush1
                     ...
                     etc.
                and not when we get WM_CLOSE !
   

meanwhile:   why you  use « INVOKE DestroyWindow,hGlobal_hWnd» AGAIN
                      when the MSG = WM_DESTROY ? Is it to destroy other windows ?
                     

[MichaelW]

The WM_CLOSE notification is sent when the user attempts to close the window, typically by clicking the close button on the title bar or selecting the Close command on the window menu (typically accessed by clicking the application icon at the left end of the title bar). The default handling of WM_CLOSE, as carried out by the default window procedure, is to call the DestroyWindow function.

[dedndave]

when the user clicks on a close box, the window is sent WM_SYSCOMMAND with wParam = SC_CLOSE
the lower 4 bits of wParam are used internally by the OS, and may be any value
so, the SC_CLOSE command could actually be any of 16 values (0F060h to 0F06Fh)

normally, we do not intercept this message - it is allowed to fall through to DefWindowProc
the default processing that occurs is a resulting WM_CLOSE message being generated

if your WndProc function has no code to handle WM_CLOSE, it should fall through to DefWindowProc
the default processing includes DestroyWindow, which destroys a window and all its' children
if you handle WM_CLOSE, you can prevent the close by exiting WndProc with EAX = 0 (rather than DefWindowProc)
actually, the value in EAX may not be too critical   :P
the point is, no call to DestroyWindow is made unless you call it or exit via DefWindowProc

the call to DestroyWindow actually removes the window from the screen
then, it sends the window a WM_DESTROY message
more specifically, it repeats this for the top window, then for each child window
this seems backwards, but notice that when WM_DESTROY code is executed, any child windows still exist

when a window receives a WM_DESTROY message, it has already been removed from the screen
as qWord mentioned in the other thread, this is the time to perform clean-up
some of the more important things are destroying any GDI object handles and freeing any allocated memory
notice that no more WM_PAINT messages will be received, so it is safe to destroy things like bitmap handles
you might think of WM_DESTROY as the "opposite" of WM_CREATE   :P

for the top-level (main) window, you should call PostQuitMessage to signal process termination
this actually places a message in the queue, signaling the message loop to terminate
the next time GetMessage is called in the message loop, it will return EAX = 0
this is generally used as an indicator to terminate the process


things are a little different when a user logs off or shuts down
you really don't have to worry about things like GDI handles, because they will all be destroyed
you may, however, want to write some last bit of data to a file or perhaps signal a device
you can even prevent the user log off or shut down, although it normally isn't considered courteous

WM_QUERYENDSESSION is sent to all applications to "ask permission" to end the session
WM_ENDSESSION is sent to applications, indicating that they are being terminated

the OS sends WM_QUERYENDSESSION to all top-level windows
again, we normally allow this to fall through to DefWindowProc
or - you can return TRUE to allow shut down to continue
if any application returns FALSE (0), shut down is aborted
however, applications that returned TRUE will still receive a WM_ENDSESSION message
the ShutdownBlockReasonCreate function should be used to prevent or delay shut down
if you have some brief code to execute, you don't need to call the function
you simply perform it before returning from WM_QUERYENDSESSION

as i mentioned, no need to DestroyWindow or PostQuitMessage or anything, really
the application will be terminated and all handles will be destroyed and any memory allocations will be freed

console applications have no message pump
but, they do receive notification in the way of control events
you can call SetConsoleCtrlHandler to set the address of a handler routine
the notifications are
CTRL_CLOSE_EVENT - the user is closing the console window
CTRL_LOGOFF_EVENT - the user is logging off
CTRL_SHUTDOWN_EVENT - the user is shutting down

[RuiLoureiro]

Very well Dave  ;)

Meanwhile you could say something about PostQuitMessage. Why to put it ?
What to do with the parameter that we give in that message ?

[dedndave]

you simply put an exit code (most of us generally return 0)
in DOS days, we used this code in batch files to indicate status (ERRORLEVEL batch commands)
that still works, too   
but, it can be retreived in other apps by calling GetExitCodeProcess
this might be done if your process creates a child process and wants a "return status"

you should avoid using a return value of STILL_ACTIVE (103h)
that value is used as an error value in GetExitCodeProcess to indicate that a process is still running

as i mentioned, when you call PostQuitMessage, a message is placed in the message queue
the exit code is placed in the wParam member of the MSG structure
it is good practice to pass the value when you call ExitProcess

Code Select Expand

    INVOKE  ExitProcess,msg.wParam

[RuiLoureiro]

Dave,
     very well !
     
     Now, suppose we call   ProcX  (in line X) of our application.
     And our ProcX create show ... a window and enter into a msg loop.
     What happen ?

[Don57]

There is one part I am still in the dark about is the DefWindowProc written by the coder or is it part of the OS.



In my code at the bottom of my WndProc loop I have as a fall through

   .ELSE

                  INVOKE DefWindowProc,hWnd,uMsg,wParam,lParam      
                   ret

It seems to work fine I just assumed it was a windows call

[dedndave]

Rui,
i am not sure i understand what you are asking
but, a single message loop handles messages for all windows of a process

now, if you are refering to creating a process....
that process continues to run, even if the process that created it is terminated

[dedndave]

Don,
yes - DefWindowProc is a system call
it provides default processing for all messages that aren't handled by your WndProc
to describe exactly what it does would be difficult, as its' behaviour varies from message to message
you would want to look up the specific message and see what it says about default processing

for certain messages and in some cases, i may want to execute some code, then exit via DefWindowProc
or - even execute DefWindowProc, then execute some special code (rare)

notice, that if you allow DefWindowProc, it returns a value in EAX that should be returned by your WndProc

for dialog boxes using a private class, DefDlgProc should be used
for dialog boxes using a system class, you generally return 0

[RuiLoureiro]

There is one part I am still in the dark about is the DefWindowProc written by the coder or is it part of the OS.



In my code at the bottom of my WndProc loop I have as a fall through

   .ELSE

                  INVOKE DefWindowProc,hWnd,uMsg,wParam,lParam      
                   ret

It seems to work fine I just assumed it was a windows call

It is an API from OS to process messagens we dont process.
It looks fine.

[RuiLoureiro]

Rui,
i am not sure i understand what you are asking
but, a single message loop handles messages for all windows of a process

now, if you are refering to creating a process....
that process continues to run, even if the process that created it is terminated

Well suppose we create our main window which has his own message loop.
Now when we click one button we call ProcX that creates another window of another class and then it enters into a second msg loop. This second loop is not the first. What happen ? Are you saying all the messages are posted into the first window ?

[dedndave]

here is a "template" WndProc
notice that it does not handle WM_CLOSE
and that it is for the main window, as it does handle WM_DESTROY by calling PostQuitMessage

this is my preference - there are other methods
but, it allows the code for each message to control the return value differently
and, the value returned in EAX from DefWindowProc is passed to the RET

Code Select Expand

WndProc PROC    hWnd:HWND,uMsg:UINT,wParam:WPARAM,lParam:LPARAM

    mov     eax,uMsg
    .if eax==WM_CREATE

        ;create code

        xor     eax,eax          ;return 0

    .elseif eax==WM_DESTROY
        INVOKE  PostQuitMessage,NULL
        xor     eax,eax          ;return 0

    .else
        INVOKE  DefWindowProc,hWnd,uMsg,wParam,lParam

    .endif
    ret

WndProc ENDP

[dedndave]

              Well suppose we create our main window which has his own message loop.
Now when we click one button we call ProcX that creates another window of another class and then it enters into a second msg loop. This second loop is not the first. What happen ? Are you saying all the messages are posted into the first window ?

a single message loop handles all messages for all windows in that thread
you can create any number of windows in a thread, and the messages are all dispatched by 1 loop

however, if you create another thread, with its' own window(s) and own loop, those are seperate

EDIT: corrected "process" to "thread" per qWord