+2  A: 

From the MSDN:

The GetMessage function retrieves a message from the calling thread's message queue

So no, what you describe is not directly possible.

jn_
+2  A: 

No.

GetMessage returns messages on the current thread's input queue. The HWND parameter is a filter, so that GetMessage only returns messages in the current thread's input queue intended for that window.

Windows have thread affinity - messages intended for a window get handled on the thread that created and therefore owns the window.

Michael
+2  A: 

In your first example the Dialog and GetMessage are in separate threads. And the documentation says:

The GetMessage function retrieves a message from the calling thread's message queue.

The second example works since the calling thread (for GetMessage) also owns the Dialog.

dirkgently
A: 

In your example programm finish after create window.

But anyway in win32 all threads have own message queue.

And all message queues get messages for windows created in this thread.

see:

http://msdn.microsoft.com/en-us/library/ms644928(VS.85).aspx (Using Messages and Message Queues)

http://msdn.microsoft.com/en-us/library/ms644936(VS.85).aspx (GetMessage Function)

bb
A: 

You can of course change the window procedure that handles messages for any window. Check the SetWindowLong function - http://msdn.microsoft.com/en-us/library/ms633591(VS.85).aspx - there are some rules as to what address space the new proc is. I suggest using a dll. Another way is to sub class the window message queue.

Martlark
A: 

Of course you can !

Just use remote code injection ! (very classic !)

(noobs always reply "no" ,as everything is always possible...)

HA! If you define "possible" to mean, "by doing something else entirely", then yes, everything is possible.
Shog9
A: 

Use AttachThreadInput.

Valentin Galea
Not possible on Windows CE/Mobile.
Johann Gerell