Use WM_WINDOWPOSCHANGED to react to window state changes

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Good Point — Tue, 15 Jan 2008 19:33:52 GMT

I think the really interesting part would be why WM_SHOWWINDOW is not sent under those certain cirsumstances.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

philq — Tue, 15 Jan 2008 19:35:11 GMT

I can't wait for tomorrow. WM_WINDOWPOSCHANGING is hands-down my favorite message. I would say it's everybody's favorite, but there is a surprising lack of discussion of favorite win32 messages on the internet. Between WM_WINDOWPOSCHANGING and AttachThreadInput() the operating system is your oyster.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Michael — Tue, 15 Jan 2008 19:44:27 GMT

Good entry as usual, but don't you mean the opposite of >>"If WM_WINDOWPOSCHANGED is redundant with WM_MOVE, WM_SIZE, and WM_SHOWWINDOW, then why do we have those other messages anyway?"<< ?

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Stephen Eilert — Tue, 15 Jan 2008 19:53:51 GMT

@Michael

"Good entry as usual, but don't you mean the opposite of >>"If WM_WINDOWPOSCHANGED is redundant with WM_MOVE, WM_SIZE, and WM_SHOWWINDOW, then why do we have those other messages anyway?"<< ?"

I don't think so. If WM_WINDOWPOSCHANGED provides more information, the others are redundant and might as well not exist.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Michael — Tue, 15 Jan 2008 19:57:05 GMT

Yes I get that, maybe I'm just thick headed but the first part of the sentence makes it sounds like it's WM_WINDOWPOSCHANGED that's redundant, which is clearly not the case.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

ulric — Tue, 15 Jan 2008 20:04:43 GMT

hum.. I'm an old-style charles-petzold kinda guy and I like the old messages. Especially since the WM_SIZE notification is generally all that a window needs. Move? Never needed it. WM_SHOWWINDOW is fine.. bizzare the client had a problem with it. I like simple messages.

btw, that sample code is a little funny, since it implies window could be both shown and hidden..

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Blech — Tue, 15 Jan 2008 20:08:09 GMT

"It sort of combines the other state change notifications, WM_MOVE, WM_SIZE, and WM_SHOWWINDOW"

I never could get my head around that. The first two I have no problem with, but WM_SHOWWINDOW? The position isn't changing, is it? Just whether it is shown or not.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Blech — Tue, 15 Jan 2008 20:11:55 GMT

"What if the window is never shown? Does this mean that the program will never initialize itself?"

Might make sense in some cases. If a program is, for example, displaying an image but is not visible why go to the expense of loading the file? It really depends what they mean by "initialize its state".

"The WM_NCCREATE and WM_CREATE are the more traditional places to do window initialization."

Maybe they really did mean application, and not window.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

John — Tue, 15 Jan 2008 20:13:09 GMT

Flags like these drive me nuts, especially in the Windows API.

Presumably you can't both show and hide a window at the same time, so why do you have separate flags for them? Also, why are some flags "negative" when the others are "positive"? Wouldn't it make more sense to check for the presence of a flag rather than the lack of a flag? "If the window was moved" makes more sense than "if the window was not not moved". This is the same thing you brought up a while ago about checkboxes with text like "Enable whatever" and "Disable whatever". Very annoying.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

noone in particular — Tue, 15 Jan 2008 20:17:50 GMT

Great stuff.

I just now learned about the existence of WM_WINDOWPOSCHANGED, and I am doing MFC-programming for 4 years now...

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Tue, 15 Jan 2008 20:49:37 GMT

"Presumably you can't both show and hide a window at the same time, so why do you have separate flags for them?"

What if the window is neither shown nor hidden, but instead was resized? What value do you propose to set the SHOW flag if 1 means the window was shown and 0 means the window was hidden? Separate flags are essential for the design of the WM_WINDOWPOSCHANGED handler.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Mike — Tue, 15 Jan 2008 21:35:53 GMT

I don't think it's strange at all to do (re-)initialization when the window is shown if you use e.g. DDraw (incl. D3D) which requires it - old contents are almost certainly lost.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

John — Tue, 15 Jan 2008 22:38:28 GMT

@J: Oops. You are correct in that regard.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Miral — Wed, 16 Jan 2008 02:38:58 GMT

"I never could get my head around that. The first two I have no problem with, but WM_SHOWWINDOW? The position isn't changing, is it? Just whether it is shown or not."

Ah, but WM_SHOWWINDOW is related to the ShowWindow API, which can both show/hide and resize windows (minimising, maximising, and restoring are all size changes). So they are related.

"Also, why are some flags "negative" when the others are "positive"? Wouldn't it make more sense to check for the presence of a flag rather than the lack of a flag?"

Because new flags are added over time, and existing programs won't be providing that flag. Therefore "flag not present" must always be "default behaviour" and "flag present" must be "modified behaviour". Sometimes the modified behaviour is telling it to do something it wasn't doing before, other times it's telling it to *not* do something that it was doing before.

So yes, it leads to non-ideal names for things, but there's not much else you can do to maintain backwards compatibility short of defining an entire new API (which is a bit of overkill for a simple flag).

re: Use WM_WINDOWPOSCHANGED to react to window state changes

AK — Wed, 16 Jan 2008 03:13:17 GMT

SWP_NOxxx flags come from SetWindowPos, has nothing to do with new flags added over time AFAIK (but, SetWindowPos should probably been implemented the other way around, where you specify a mask of valid params instead of excluding stuff, but too late for that now ofcourse)

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Sarath — Wed, 16 Jan 2008 03:59:42 GMT

I've used this message before to detect Scrollbar available or not by GetWindowLog()

re: Use WM_WINDOWPOSCHANGED to react to window state changes

hexatron — Wed, 16 Jan 2008 07:47:12 GMT

I suppose if I thought about this, it would explain why, under Windows 3.0, I never used ShowWindow, but instead moved the windows off- or on-screen with MoveWindow. But I won't.

I notice the WM_WINDOWPOSCHANGED documentation says all this good stuff I never knew (this message generates the WM_MOVE,etc, and you are better off reacting to these in the WM_WINDOWPOSCHANGED). It makes me think I should re-read all the Win32 documentation (never mind MFC and the outer darkness of non-C/C++ windows programming). Then I remember I probably only have one human lifetime at my disposal, and I've already squandered most of that.

re: Use WM_WINDOWPOSCHANGED to react to window state changes

hexatron — Wed, 16 Jan 2008 08:18:22 GMT

As for flag, I just did a count of the 2002 Windows SDK:

The include files together contain about 100,000 #defines.

Of these, 625 are evaluate directly as 0 (or 0L, 0x0000, etc). Of course, many more are indirectly zero (#define ZERO 0 & #define HIDDENZERO ZERO)

The memorable one is FILE_ATTRIBUTE_NORMAL, as in

if(attributes & FILE_ATTRIBUTE_NORMAL){

/// in your dreams, sucker!!!

}

re: Use WM_WINDOWPOSCHANGED to react to window state changes

Blech — Thu, 17 Jan 2008 20:02:14 GMT

> Ah, but WM_SHOWWINDOW is related to the ShowWindow API, which can both show/hide and resize windows (minimising, maximising, and restoring are all size changes). So they are related.

I'm related to my father, but it doesn't mean he can get passed to all the functions I can.

Custom Window Chrome in WPF

Windows Presentation Foundation SDK — Mon, 08 Sep 2008 21:05:02 GMT

Guest post by Joe Castro, WPF product team developer This document covers the design and some implementation