Printable View
Hello all -
I'm handling the WM_ENTERSIZEMOVE message to perform some processing of my window. But I'll need to know whether its a size or a move for some of my logic. Is there a good way to determine this during the handling of the WM_ENTERSIZEMOVE message? I thought at first I could handle the WM_NCHITTEST and save the result, but that wouldn't handle the case where the user invoked the Move or Size items from the system menu via the task bar. Thanks in advance for any thoughts.
- Steve
What kind of processing are you going to perform in respond to WM_ENTERSIZEMOVE message?
Why not to do it in WM_WINDOWPOSCHANGING or WM_WINDOWPOSCHANGED or WM_SIZE or WM_GETMINMAXINFO or some other message handler?
In my scenario, I need the entire desktop to dim at the point the user is thinking about moving the window, so that only the active window being moved is colorized (giving more emphasis to this window). If the user does a left-button down on the caption of this window, a WM_ENTERSIZEMOVE is generated right away. It's at this point I need the desktop to dim in preparation for a move. Handling any of the other messages you mention happens too late - i.e., they only get fired when a move has actually happened. But handling the WM_NCLBUTTONDOWN or WM_NCHITTEST isn't enough here either, because the user could invoke the 'Move' from the system menu. The common thread between the two is the WM_ENTERSIZEMOVE call, which is called in either case. However it doesn't tell me whether it's a size or a move, which I'd need to know in this case because I don't want to dim the desktop on a window size. So the question remains.
But you cannot know it until a user chose either move or size!Quote:
Originally Posted by sjc
What is wrong with WM_WINDOWPOSCHANGING message?
If the left button is down, you should be able to tell either by getting the vertical position of the mouse cursor (i.e. is it at the very top of the title bar) or alternatively, by getting the mouse cursor. Try it yourself and notice that when you hover your mouse very close to the top of the title bar, Windows changes the cursor. So by examining either the vertical position or the cursor itself, you can tell whether the intended operation will be a resize or a move....Quote:
Originally Posted by sjc
Or even easier, examine wParam. When WM_ENTERSIZEMOVE gets sent, it looks like wParam indicates whether the user is moving or sizing.
But MSDN writes:Quote:
Originally Posted by John E
:confused:Quote:
Parameters
wParam
This parameter is not used.
lParam
This parameter is not used.
Ah yes.... SC_SIZE or SC_MOVE are sent as a parameter along with the WM_SYSCOMMAND message. My first option would be to try and find out if that gets sent when using the mouse to move/resize or only when using the sys menu. If it only gets sent in response to the relevant menu command, determining the mouse's position (or cursor type) might be a more reliable option.
Believe me, I've researched all these messages. I'm already handling the WM_WINDOWPOSCHANGING for the majority of my actual work (and have considered WM_MOVING), but that only gets called once a move or size has happened. The user can enter a move/size loop without actually changing the position or size of the window, as is the case when the user left-clicks down on the caption area. A WM_ENTERSIZEMOVE is fired by the OS and its here where I need to do some initial work and UI changes to indicate that a move is about to happen (which is the reason for my question, because I don't want to do these UI changes if a size is about to happen). I needed to handle both the case where the user was doing this with the mouse button on the non-client area of the frame, and when Move was executed from the system menu. The OS knows what it's about to enter, that's why it sends the WM_ENTERSIZEMOVE, and it already covers both cases. It seems like the exact message I should be handling for my purpose, I just wish the OS send a flag indicating which one it was (it knows, it's just not telling me). Anyway, thanks for your thoughts and suggestions.
No, that is not correct. From MSDN:Quote:
Originally Posted by sjc
Quote:
WM_WINDOWPOSCHANGING message (Windows)
Sent to a window whose size, position, or place in the Z order is about to change as a result of a call to the SetWindowPos function or another window-management function.
Parameters
wParam
This parameter is not used.lParam
A pointer to a WINDOWPOS structure that contains information about the window's new size and position....
Remarks
...
While this message is being processed, modifying any of the values in WINDOWPOS affects the window's new size, position, or place in the Z order. An application can prevent changes to the window by setting or clearing the appropriate bits in the flags member of WINDOWPOS.