CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 28 of 28
  1. #16
    Join Date
    Mar 2005
    Posts
    16

    Re: scrolling popup menu via Page Up/Down

    subclassing" in windows terminology does not mean "derive a class from a base class (such as CWnd).
    Right you are. There is some overloading of the term, hence confusion. But the code snippet I posted is subclassing in the sense you mean, specifically the "old" (pre-common controls 6) subclassing technique, AKA replacing the window procedure as described in the MS Subclassing Controls article.

    once menu window does not process page keys, and provides no other API to be controlled with the way you need, you have no option but to accept this humbly
    I might accept it, but only due to time constraints, and definitely not humbly. Resentfully would be more like it. In my view this hiding of the menu scrolling API, which is obviously extant and useful, is just more MS obstructionism of the same type that was so resoundingly (albeit temporarily) defeated in the 2001 antitrust suit.
    Last edited by ckorda; July 9th, 2014 at 02:22 PM.

  2. #17
    Join Date
    Mar 2005
    Posts
    16

    Re: scrolling popup menu via Page Up/Down

    If you are not getting messages for pageup/down what does your message loop code look like?
    The message loop was shown in post #12 above. The fact is that if I subclass (as in replace the window procedure of) a popup menu window, my window procedure does not receive any messages at all for the Page Up/Down and Home/End keys. It DOES receive messages (either WM_CHAR or WM_KEYDOWN) for most other keys, including the arrow keys. I am unclear on how this can be the case. I was under the impression that when a window is subclassed, the "new" window procedure gets first crack at ALL messages. Could it be that the popup menu's window is somehow disabling the page up/down and home/end keys? I thought of WM_GETDLGCODE but I don't receive this either.

  3. #18
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: scrolling popup menu via Page Up/Down

    T
    he message loop was shown in post #12 above
    Post #12 does not show a message loop.
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

  4. #19
    Join Date
    Mar 2005
    Posts
    16

    Re: scrolling popup menu via Page Up/Down

    Post #12 does not show a message loop.
    Would you care to elaborate on how the code below differs from a message loop? My impression was that a window procedure is the most basic form of message loop, and that CWnd and message maps and so on are just wrappers around this functionality.

    Code:
    WNDPROC wpOldMenuProc;
    LRESULT CALLBACK MenuWndProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
    {
    	switch(uMsg) {
    	case WM_CREATE:
    		printf("!");
    		break;
    	case WM_KEYDOWN:
    		printf("k=%x ", wParam);
    //		::MoveWindow(hWnd, 0, 0, 100, 100, 1); // works fine but not helpful
    		{
    			CRect	r;
    			::GetClientRect(hWnd, r);
    			::ScrollWindow(hWnd, 100, 0, 0, r);  // doesn't work, -100 doesn't work either
    		}
    		return 0;
    	}
    	printf("%x ", uMsg);
    	return CallWindowProc(wpOldMenuProc, hWnd, uMsg, wParam, lParam);
    }

  5. #20
    Join Date
    Mar 2005
    Posts
    16

    Re: scrolling popup menu via Page Up/Down

    My test app now successfully catches Page Up/Down and Home/End during a popup menu, via a message filter hook (WH_MSGFILTER). This solves the first of the two problems posed in post #12. The second problem (how to tell the menu to scroll) is considerably harder. So far the only method I've found that works at all is to repeatedly send VK_DOWN or VK_UP key down messages to the popup menu's window. This is better than nothing, but not really satisfactory because it confuses the selected item with the scroll position. I investigated secret menu messages, and found quite a few (see below) but none that seem likely to cause scrolling though I haven't tried them all. Any ideas?

    Code:
    // copy from windows\media\avi\inc.16\windows.inc(1500)
    #define MN_SETHMENU              0x01E0
    #define MN_GETHMENU              0x01E1
    #define MN_SIZEWINDOW            0x01E2
    #define MN_OPENHIERARCHY         0x01E3
    #define MN_CLOSEHIERARCHY        0x01E4
    #define MN_SELECTITEM            0x01E5
    #define MN_CANCELMENUS           0x01E6
    #define MN_SELECTFIRSTVALIDITEM  0x01E7
    //;MN_GETPPOPUPMENU       = 01EAh ;Win32
    //;MN_FINDMENUWINDOWFROMPOINT = 01EBh ;Win32
    //;MN_SHOWPOPUPWINDOW     = 01ECh ;Win32
    //;MN_BUTTONDOWN          = 01EDh ;Win32
    //;MN_MOUSEMOVE           = 01EEh ;Win32
    //;MN_BUTTONUP            = 01EFh ;Win32
    //;MN_SETTIMERTOOPENHIERARCHY = 01F0 ;Win32

  6. #21
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: scrolling popup menu via Page Up/Down

    Out of curiosity, what operating system versions are you testing this on?

  7. #22
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: scrolling popup menu via Page Up/Down

    Quote Originally Posted by ckorda View Post
    Would you care to elaborate on how the code below differs from a message loop?
    For info about a message loop see
    http://msdn.microsoft.com/en-us/libr...#creating_loop
    http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

    In WIN32 code the message loop should look something like
    Code:
    BOOL bRet;
    
    while( (bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0)
    { 
        if (bRet == -1)
        {
            // handle the error and possibly exit
        }
        else
        {
            TranslateMessage(&msg); 
            DispatchMessage(&msg); 
        }
    }
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

  8. #23
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: scrolling popup menu via Page Up/Down

    the code in #12 definately does not do subclassing. Rather, it changes the WindowClass.
    That might be ok for your particular case, but it's a rather dangerous approach since it changes the behaviour for ALL menu's, not just the one menu you're interested in.
    This could wreak havoc for any sort of tools or other code that executes in your application context (such as for example, the UI of a printer driver...)

    I might accept it, but only due to time constraints, and definitely not humbly. Resentfully would be more like it. In my view this hiding of the menu scrolling API, which is obviously extant and useful, is just more MS obstructionism of the same type that was so resoundingly (albeit temporarily) defeated in the 2001 antitrust suit.
    Actually, you are stubbornly insisting that you want to do it "your way" regardless of user perception.

    A menu is not an ideal UI concept if you have hundreds of items in it. That pretty much screams at you to find "a better way".
    Maybe by structuring your menu differently to have submenu's (but even that has it's limits in usability), or changing your concept entirely. ANd yes, that might even involve quite a bit more than just flat out replacing the menu with something else, but thinking about what you're trying to do and find a user friendly/intuitive way to achieve the same goal.

    Everything about the menu you are using is exposed.
    Some parts of the menu behaviour (such as the autoscrolling) can't be targetted directly because there's simply no API for it.
    Microsoft products have either stopped using a menu (using ribbon now), or are using a different control that "more or less" looks the same.
    Microsoft is in no way required to release code, or even API's of controls they develop specifically for their own products (yes, it's annoying sometimes), but I would also like some controls that are in other 3rd party products. Just because the company that made the OS and the one that made your spreadsheet are one and the same does not matter in that case.

    Get your facts straight, the antitrust issues from 2001 are in no way or form even remotely relevant in this discussion. That was all about MS releasing the mediaplayer as part of the OS, and some idiots deciding that was a bad idea, so they forced MS to make a version of windows without media player (WIndows N), that they ended up selling for a bit higher price, so nobody really ever bought it.



    The problem with WM_KEYDOWN is probably that the frame the menu is attached to has already processed the PgDn.

  9. #24
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: scrolling popup menu via Page Up/Down

    Quote Originally Posted by 2kaud View Post
    For info about a message loop see
    http://msdn.microsoft.com/en-us/libr...#creating_loop
    http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

    In WIN32 code the message loop should look something like
    Code:
    BOOL bRet;
    
    while( (bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0)
    { 
        if (bRet == -1)
        {
            // handle the error and possibly exit
        }
        else
        {
            TranslateMessage(&msg); 
            DispatchMessage(&msg); 
        }
    }
    that is a messageloop
    but subclassing is not about changing the messageloop itself,
    but changing the "callback" function (windowsprocedure) Windows will call when there are messages to be processed (in response of the messageloop)

  10. #25
    Join Date
    Mar 2005
    Posts
    16

    Re: scrolling popup menu via Page Up/Down

    This could wreak havoc for any sort of tools or other code that executes in your application context
    The popup menu places the app in a modal state which is easy to identify. It's no problem to arrange things so that the special handling is only enabled in the desired case. The rest of the time the new window procedure just calls the old window procedure and menu behavior is totally unchanged. I get that you're not a fan of scrolling popup menus, but I'd like to stay focused on how to do it. The message filter Window hook solves the first problem (non-receipt of Page Up/Down and Home/End). The only outstanding difficulty is how to scroll the menu, or rather how to do so more gracefully than by sending it VK_UP/VK_DOWN key messages.

    the antitrust issues from 2001 are in no way or form even remotely relevant
    Not so. The only reason we know many crucial details about Windows, particularly Explorer-related interfaces and protocols, is because the 2001 settlement forced MS to publish them. See e.g. Microsoft To Publish 385 Windows APIs, Protocols To Make Antitrust Case Go Away. It's relevant to this discussion because the settlement was merely a temporary victory, and old habits were quickly reasserted. The menu API is needlessly obfuscated, people have been complaining about it for years, and this is just one of many examples of anti-competitive behavior.

    "On November 2, 2001, the DOJ reached an agreement with Microsoft to settle the case. The proposed settlement required Microsoft to share its application programming interfaces with third-party companies and appoint a panel of three people who will have full access to Microsoft's systems, records, and source code for five years in order to ensure compliance." United States v. Microsoft Corp.
    Last edited by ckorda; July 10th, 2014 at 11:17 AM.

  11. #26
    Join Date
    Mar 2005
    Posts
    16

    Re: scrolling popup menu via Page Up/Down

    Out of curiosity, what operating system versions are you testing this on?
    Windows 7, see post #1.

  12. #27
    Arjay's Avatar
    Arjay is offline Moderator / EX MS MVP Power Poster
    Join Date
    Aug 2004
    Posts
    13,490

    Re: scrolling popup menu via Page Up/Down

    Quote Originally Posted by ckorda View Post
    Windows 7, see post #1.
    I saw that but wasn't sure since you mentioned common controls 6 and referenced very old articles.

  13. #28
    Join Date
    Nov 2000
    Location
    Voronezh, Russia
    Posts
    6,620

    Re: scrolling popup menu via Page Up/Down

    Quote Originally Posted by ckorda View Post
    The menu API is needlessly obfuscated, people have been complaining about it for years, and this is just one of many examples of anti-competitive behavior.
    When you design some functionality, there always public and private parts exist. And it's generally up to you how far public part goes.

    I'm in Windows programming since 1996, and frankly, you are the first person I met ever who demands to extend standard menu API. Besides, the "old" API inherited from classical Win16 always was kind of rigid. And I completely understand why MS never tried to improve it, as the effort (design, implementation, testing, documenting, training, etc.) is hardly worth the results.

    "On November 2, 2001, the DOJ reached an agreement with Microsoft to settle the case. The proposed settlement required Microsoft to share its application programming interfaces with third-party companies and appoint a panel of three people who will have full access to Microsoft's systems, records, and source code for five years in order to ensure compliance." United States v. Microsoft Corp.
    Again, I completely understand all the fuzz about exposing IE guts and being able to expel the one from the system, as there's really a place for competition. But competing in pop-up menus... it's something beyond my understandings.
    Best regards,
    Igor

Page 2 of 2 FirstFirst 12

Tags for this Thread

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