2

I have a problem with WM_SIZE. I want to capture it using PeekMessage (not WndProc). PeekMessage never receives WM_SIZE, so I post extra user message to window to capture it with PeekMessage like this (code from WnProc) :

case WM_SIZE:
  PostMessageW(hwnd, WM_USER + 1, wParam, lParam);
  break;

The problem is I receive WM_USER + 1 using PeekMessage only when window is maximized or restored. No message when window is resized by its thick frame (I receive WM_SIZE in WndProc though).

Demion
  • 857
  • 1
  • 14
  • 27
  • You post your `WM_USER+1` message from the `WndProc`? – Benlitz Jun 11 '12 at 16:57
  • Yes I post WM_USER + 1 from my WndProc, because PeekMessage by itself never receive WM_SIZE. I checked PostMessageW and it is called returning success every time I resize window. But PeekMessage receive it only when window is created, maximized, restored (not when resized by its thick frame). – Demion Jun 11 '12 at 17:10
  • 1
    It seems very likely that you have chosen the wrong solution to your problem. But with no knowledge of the problem, we are unable to advise you on what would be the right solution. – David Heffernan Jun 11 '12 at 18:18

2 Answers2

7

PeekMessage() can only see messages that were posted to the message queue. That excludes WM_SIZE, it is sent, not posted. Or in other words, it is delivered by SendMessage(), it calls the window procedure directly and bypasses the message queue. So yes, your code starts working because you now repost the message with PostMessage, it is put on the message queue so PeekMessage can see it.

Something different happens when the user resizes the window. That's reported by another message: WM_SIZING. It is generated, at a pretty high rate, when Windows starts a modal message loop to implement the resizing operation. It gives due notice of this, you'll get the WM_ENTERSIZEMOVE when the modal loop starts (user clicks a window corner), WM_EXITSIZEMOVE when it is complete (user releases the button). You'll get a bunch of WM_SIZING messages, sent to your window procedure. Not posted. And one WM_SIZE to give the final size. One way to not see these reflected versions of these messages is when you call PeekMessage() in your own message loop. It won't be called when the Windows modal resize loop is active.

Hard to give better advice, it is really unclear why you are doing this. The "doctor, it hurts, don't do it then" medical answer is highly likely to be relevant. I suspect you might want to reflect the WM_SIZING message as well. The largest issue is that by the time you retrieve these messages from the queue, the window size has already changed and the notification is just plain stale. Which is why the message is sent and not posted.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

I believe this is applicable:

PeekMessage not getting the message?

You need to pass your class pointer to the last parameter of your call to CreateWindowEx, then retrieve that pointer from the LPCREATESTRUCT passed to you in the LPARAM of WM_CREATE, your class pointer will be in the lpCreateParmas feild of the struct. Set your class pointer to the GWLP_USERDATA of your window, and on any other message calls , call GetWindowsLong , retrieve your class pointer, then pass the message, wparam, and lparam all off to your internal class message handler.

http://msdn.microsoft.com/en-us/library/ff381400%28v=VS.85%29.aspx

Community
  • 1
  • 1
paulsm4
  • 114,292
  • 17
  • 138
  • 190
  • I've seen this question. This is not actual answer to my question. This is probably another solution but not as I requested (receive every WM_SIZE or WM_USER + 1 using PeekMessage). – Demion Jun 11 '12 at 17:17
  • 1
    @Demion: But this answer removes the need for your work around. Why try to fix the work around if you can fix the real problem? – Jeff Yates Jun 11 '12 at 17:30