About window message pump

[jdoe]

Hi,

There is something I don't understand about messages. Let see the DialogProc below.

How can the SendMessage function returns when it send a WM_SETTEXT message to the DialogProc where SendMessage is called ?
What is the mechanism behind that ?

Code Select Expand



DialogProc PROC hWndDlg:DWORD, uMsg:DWORD, wParam:DWORD, lParam:DWORD

    .IF (uMsg == WM_INITDIALOG)

        INVOKE SendMessage, hWndDlg, WM_SETTEXT, NULL, ADDR szText

    .ELSEIF (uMsg == WM_CLOSE)

        INVOKE EndDialog, hWndDlg, NULL

    .ELSE

        mov eax, FALSE
        ret

    .ENDIF

    mov eax, TRUE
    ret

DialogProc ENDP



[BogdanOntanu]

Simple recursion and the re-entrancy of the dialog callback procedure?

More exactly: the recursion does finish because you do not handle WM_SETTEXT in your dialog and more important because you do not send the message on the WM_SETTEXT handler (that would be a "small" problem :D )

[jdoe]

So I must conclude that the window message queue is asynchronous. I thought that a message could be sent only when the previous one was processed in a kind of first-in/first-out. Or in fact it is first-in/first-out but the message that finish first has no importance once he left the queue.

Thinking about it, that's logic, otherwise it would be damn slow.

Thanks

:U

[Rainstorm]

jdoe, dunno if am right.. but i thought.. that the msg is sent to the system..& so the system performs the function and returns the value.
the hwnd parameter in the msg is probably for the system to know which window/control (so to speak) the msg is associated with . so in other words..the msg doesn't reach the dialogproc mantained in the the application code.

[BogdanOntanu]

There are two kind of messages:
1) PostMessage - returns immediately after adding the message to a queue that will be processed at a later time
2) SendMessage - sends message to the callback immediately and does not return until the callback does not return.

[lingo]

"There are two kind of messages:..."
There are more... :wink
The faster way is using DispatchMessage(push one parameter)
rather than SendMessage(push four parameters)

[tenkey]

There are basically two types of message queues, Send queues and Post queues. DispatchMessage does not use a queue, it is normally used after a message has been pulled out of a Post queue with GetMessage or PeekMessage. A dialog procedure is not a window procedure, but it is invoked by a window procedure assigned to a dialog.

"Send" messages go into a Send queue if the receiving code is in a different thread. The receiving code will be a window procedure. The thread sending the message will be suspended until the receiver "replies" with a return value. If the receiving code is in the same thread, the receiving code will be invoked as if it were a subroutine - such a message does not go into a queue. There are SendMessage functions that have the option of aborting the Send. GetMessage and PeekMessage will invoke the destination window procedure for any Send messages in the queue - they will not give these messages to the GetMessage/PeekMessage invoker.

"Post" messages always go into a Post queue, which is sometimes used as a thread message queue. Posted messages are retrieved with GetMessage or PeekMessage, and are not automatically sent to a window procedure. Posted messages don't need to have a window as a destination. Posted messages can sit in the queue for any amount of time. It can be processed immediately, or it might be forced to wait in the queue. There is some special handling for some Post message types: keyboard, mouse, timer, paint, and quit.

[kromag]

You could also check on this using tools like Spy++ or Winspector Spy along with Sysinternals ProcMon.
---
Will.