locked
NC messages oddity RRS feed

  • Question

  • I'm using VC++ Express to create a DLL for a global hook system I'm writing.  The unusual thing is that as I'm trying to catch the non-client messages I can't seem to get the to trigger properly.  For example I'm trying to catch the WM_NCRBUTTONUP message anywhere on the non-client area and it doesn't trigger unless I click the tiny little border around the non-client buttons.  If I click directly on the minimize button ... nothing happens except for the system menu popup, but if I click on the tiny little border around the minimize button, the callback triggers.  Could anyone possibly explain this behavior to me or tell me what in the world I'm doing wrong?
    Wednesday, May 31, 2006 10:13 PM

Answers

  • Sorry to disagree.  Say that somebody wanted to capture WM_RBUTTONUP in the window menu.  If Windows would send a WM_NCRBUTTONUP just because the click got started by clicking on the minimize button, he'd be dead in the water.  Arguably, capturing mouse clicks on a menu are a bit more common than on a minimize button.

    The behavior is different when you've got the classic window appearance selected, right-clicking the minimize button does not display the window menu and you'll always get a WM_NCRBUTTONUP.

    As a workaround, you could record WM_NCRBUTTONDOWN, then look for any RBUTTONUP message to know that the minimize button got right-clicked.  Or just do what you want to do (an easter egg?) when you see WM_NCRBUTTONDOWN.  Note however that this may well stop working when Microsoft invents a new theme.  When Raymond Chang does his compability tests, he'll make sure 99.99% of the programs still work.  But he'll miss this...
    Friday, June 2, 2006 12:14 PM
    Moderator

All replies

  • Ok, here's a little update.  Using the following callback function:


    LRESULT CALLBACK GetMessageProc(int nCode, WPARAM wParam, LPARAM lParam)
    {
     if (nCode < 0)
      return CallNextHookEx(hGetMessage, nCode, wParam, lParam);

     MSG* msg = (MSG*)lParam;
     HWND hWnd = msg->hwnd;
     
     if (msg->message == WM_NCRBUTTONUP)
      MessageBoxW(::GetActiveWindow(),L"DLL Internal Callback triggered!",L"Internal Callback Notification", MB_OK);

     return CallNextHookEx(hGetMessage, nCode, wParam, lParam);
    }


    What happens with this code is when I right click either the close button or the maximize button on any window I get my messagebox, but if I right click on the minimize button... the one I want to capture anyway, I get the system menu and no messagebox.  Why am I Having such a hard time with this?  Any ideas?

    -W

    Thursday, June 1, 2006 3:06 AM
  • Yet another update.. I'm REALLY getting confused.  It doesn't matter if I use the GetMessage hook or the Mouse hook, my minimize button doesn't seem to get detected right from my code.  It appears it was not the border I was clicking to get the result.  If I right click the minimize button dead center, I get a system menu and no messagebox for either hook.  If I fade my mouse to the right toward the maximize button almost to the edge of the minimize button then the hooks trigger.  Both of them.  So apparently my DLL is detecting my minimize button off center. As if it was overlapped by the maximize button.  Can anyone shed some light on my mistake?  I'm not doing any pointer detect, strictly looking for NCRBUTTONUP and HTMINBUTTON.  Note however if I'm using the left click.. the minimize button works fine.  In addition if I use someone else' tray minimizing application and right click the min button to minimize to tray, it works fine.  This has to be a bug with VS Express or something really goofy I can't figure out.
    Thursday, June 1, 2006 3:57 AM
  • I looked with Spy++, highly recommended if you are trying to debug stuff like this.  I see a WM_NCRBUTTONDOWN message, followed by WM_RBUTTONUP.  Note: NOT WM_NCRBUTTONUP.  That's probably because the mouse is now over the menu and no longer over the non-client area.  Makes sense to me...
    Friday, June 2, 2006 3:22 AM
    Moderator
  • Did you try this clicking far to the right side of the minimize button like almost to the edge to see if it has the same results?
    Friday, June 2, 2006 3:45 AM
  • I don't have anything but the express versions of VStudio so Spy++ is not available to me, however I got myself a utility that does the same thing.  Interestingly enough I ended up with results like you described.

    This has to be a problem with the API because I used the spy on a standard explorer window with nothing else running and if I right click the min button in the middle I get a NCRBUTTONDOWN and a RBUTTONUP.  However if I click the min button over to the right near the edge I get a NCRBUTTONDOWN and NCRBUTTONUP.  What this means to me is that it's not a bug in my code.  So how in the heck are people writing apps that catch the right click on the min button.  I know they are doing it because i have one.  I just want to know the workaround.  I wonder if MS is aware of this little glitch.

    I asked a friend to try this on his computer and he did NOT get the same results so there must be some commonality that we have causing this issue.

    Friday, June 2, 2006 4:12 AM
  • Sorry to disagree.  Say that somebody wanted to capture WM_RBUTTONUP in the window menu.  If Windows would send a WM_NCRBUTTONUP just because the click got started by clicking on the minimize button, he'd be dead in the water.  Arguably, capturing mouse clicks on a menu are a bit more common than on a minimize button.

    The behavior is different when you've got the classic window appearance selected, right-clicking the minimize button does not display the window menu and you'll always get a WM_NCRBUTTONUP.

    As a workaround, you could record WM_NCRBUTTONDOWN, then look for any RBUTTONUP message to know that the minimize button got right-clicked.  Or just do what you want to do (an easter egg?) when you see WM_NCRBUTTONDOWN.  Note however that this may well stop working when Microsoft invents a new theme.  When Raymond Chang does his compability tests, he'll make sure 99.99% of the programs still work.  But he'll miss this...
    Friday, June 2, 2006 12:14 PM
    Moderator