CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 9 of 9
  1. #1
    Join Date
    Mar 2002
    Location
    Chicago, IL
    Posts
    255

    WM_ENTERSIZEMOVE - size or move?

    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

  2. #2
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: WM_ENTERSIZEMOVE - size or move?

    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?
    Victor Nijegorodov

  3. #3
    Join Date
    Mar 2002
    Location
    Chicago, IL
    Posts
    255

    Re: WM_ENTERSIZEMOVE - size or move?

    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.

  4. #4
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: WM_ENTERSIZEMOVE - size or move?

    Quote Originally Posted by sjc View Post
    ... 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!
    What is wrong with WM_WINDOWPOSCHANGING message?
    Victor Nijegorodov

  5. #5
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: WM_ENTERSIZEMOVE - size or move?

    Quote Originally Posted by sjc View Post
    If the user does a left-button down on the caption of this window, a WM_ENTERSIZEMOVE is generated right away. [...] 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
    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....

    Or even easier, examine wParam. When WM_ENTERSIZEMOVE gets sent, it looks like wParam indicates whether the user is moving or sizing.
    Last edited by John E; November 19th, 2012 at 05:59 AM.
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  6. #6
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: WM_ENTERSIZEMOVE - size or move?

    Quote Originally Posted by John E View Post
    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:
    Parameters
    wParam
    This parameter is not used.
    lParam
    This parameter is not used.
    Victor Nijegorodov

  7. #7
    John E is offline Elite Member Power Poster
    Join Date
    Apr 2001
    Location
    Manchester, England
    Posts
    4,835

    Re: WM_ENTERSIZEMOVE - size or move?

    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.
    "A problem well stated is a problem half solved.” - Charles F. Kettering

  8. #8
    Join Date
    Mar 2002
    Location
    Chicago, IL
    Posts
    255

    Re: WM_ENTERSIZEMOVE - size or move?

    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.

  9. #9
    VictorN's Avatar
    VictorN is offline Super Moderator Power Poster
    Join Date
    Jan 2003
    Location
    Hanover Germany
    Posts
    20,396

    Re: WM_ENTERSIZEMOVE - size or move?

    Quote Originally Posted by sjc View Post
    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.
    No, that is not correct. From MSDN:
    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.
    Victor Nijegorodov

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured