3

I have a fairly simple windows program that created a listview control that should exactly fill the client area. That works at start up, and I think will work if the window is resized --- except the windows NEVER receives any WM_SIZE messages (after the initial one sent on window creation.) I verified this using Spy++x64 as an administrator to ensure I was capturing everything. Spy++ showed the window receiving WM_SIZING, WM_WINPOSCHANGED, WM_NCCALCSIZE, and WM_WINPOSCHANGING (this list isn't in any particular order) but NEVER a WM_SIZE.

This is a 64-bit program, but I don't know why that should matter.

So, is there something I could have done that allows the window to be completely resizable, but prevent Windows from ever generating WM_SIZE messages when that happens? If not, is there something I need to do (that was never needed in the past 30 years) to let Windows know I need to see those WM_SIZE events?

Steve Valliere
  • 1,119
  • 7
  • 12

1 Answers1

2

It turns out that the default window procedure generates the WM_SIZE when it processed WM_WINDOWPOSCHANGED and, since I was handling WM_WINDOWPOSCHANGED, no size messages were created. So I forwarded the position changed message to the default handler and the messages are back.

This follows documented behavior. There's a remark in the documentation for the WM_WINDOWPOSCHANGED documentation:

By default, the DefWindowProc function sends the WM_SIZE and WM_MOVE messages to the window. The WM_SIZE and WM_MOVE messages are not sent if an application handles the WM_WINDOWPOSCHANGED message without calling DefWindowProc. It is more efficient to perform any move or size change processing during the WM_WINDOWPOSCHANGED message without calling DefWindowProc.

Yup, I'm sorry to admit that I failed to read the documentation for all of the Window messages that I was NOT having problems with when I needed to find out about WM_SIZE. Silly me for not assuming the documentation I needed about WM_SIZE was only to be found under some other message! All it says about the message generation in the WM_SIZE documentation is:

Sent to a window after its size has changed.

There is no mention AT ALL of any dependency on the default processing for a DIFFERENT message to be found. Ergo, the behavior is effectively undocumented, especially since it may be critical information, as it was for me.

Oh well, I give up, this place has become far too much of just smacking people down for asking questions some people think are too easily answered. Try to remember that not everyone has an eidetic memory and access to all of the documentation you have all memorized. Some of us look up the thing we're working on and expect to find the important details about it. THEY ARE NOT PRESENT. Bye!

Steve Valliere
  • 1,119
  • 7
  • 12
  • 1
    [WM_WINDOWPOSCHANGED](https://learn.microsoft.com/en-us/windows/win32/winmsg/wm-windowposchanged): *"By default, the [DefWindowProc](https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-defwindowprocw) function sends the `WM_SIZE` and `WM_MOVE` messages to the window. **The `WM_SIZE` and `WM_MOVE` messages are not sent if an application handles the `WM_WINDOWPOSCHANGED` message without calling `DefWindowProc`**."* – IInspectable Apr 06 '20 at 18:40
  • @Steve Valliere: Inspectablle was first, but this is DOCUMENTED behavior – user2120666 Apr 06 '20 at 18:42
  • @IInspectable: I dont consent with you, OP blamed Microsoft that this behaviour is not documented, but in reality is it. So downvote.How is answer helpful? I dont understand. – user2120666 Apr 06 '20 at 18:57
  • 2
    @use: This is no longer the case. You are allowed to un-down-vote a contribution once it has been edited. – IInspectable Apr 06 '20 at 19:21
  • 1
    @IInspectable: NO. If user dont want read documentation, dont deserve un-down-vote. Its like: "I stop the chainsaw my hand, but dont read manual. Now when my hand is gone, I read this manual. Please un-down-vote me" – user2120666 Apr 06 '20 at 19:34
  • FWIW, I was looking at Microsoft's online documentation and they have revised it so that these messages both refer to each other now, instead of WM_WINDOWPOSCHANGED not being referenced at all in the WM_SIZE and WM_MOVE message documentation. – Steve Valliere Jul 27 '20 at 14:51