4
votes

Does anyone know the WM_MESSAGE that is sent when a window has been maximized (either by the maximize button being pressed in the title bar, or by double clicking the title bar?)

Is there a windows message for the maximize button being pressed?

Win32/C++, thanks.

2
It's unusual for this information to be terribly useful... what is this for? (To correctly save maximized state of window for later restoring, use GetWindowPlacement/SetWindowPlacement rather than, say, GetWindowRect/SetWindowPos. To remove maximize button, omit the WS_MAXIMIZEBOX flag in CreateWindow. To limit window size, handle WM_SIZING. And so on.) With apologies for trying to second-guess a simple question, as I hate it when people do that.Tom Seddon
I have disabled both WM_PAINT and WM_ERASEBKGRND from my program to be able to display un-double buffered images without having them flicker. I needed to know the window message that was sent on window maximize because after I clicked my maximize button, the images did not appear where I wanted them to (so I wanted to handle the maximize button event to have the images placed where I wanted them on press).James Diaz
I bet you forgot the CS_VREDEAW | CS_HREDRAW styles.Raymond Chen
The problem persists whether I change those styles to null, or not (I tried both). I have no idea why WM_MOVE is being called on WM_SIZE(window maximized). Though, I would guess the window IS moving when being maximized (kinda).James Diaz

2 Answers

3
votes

You get the WM_SIZE message with the value SIZE_MAXIMIZED in wParam

Edit

The @jamesdlin comment bellow called my atention to WM_WINDOWPOSCHANGED documentation, which states (emphasis mine):

Remarks 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.

Thanks james!

1
votes

I dealt with this recently, and the approach I settled on was to check IsZoomed in response to WM_WINDOWPOSCHANGED, comparing its result to the previous one to detect when a transition occurs, and then to forward WM_WINDOWPOSCHANGED to the default window procedure.

If you have complete control over the message handling in your application and know that there isn't (and won't ever be) a WM_WINDOWPOSCHANGED handler that suppresses WM_MOVE/WM_SIZE, then you should be able to handle it directly in a WM_SIZE handler as described in jachguate's answer.