Announcement

Collapse
No announcement yet.

Menus on a Dialog, Underline Hotkeys Question

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Menus on a Dialog, Underline Hotkeys Question

    On several applications I have - Firefox, and Outlook two in particular, the top level menus always show their keyboard hotkeys (such as Alt+F, etc.). If I create a dialog in PB, those hotkeys do not appear until the Alt key is pressed.

    Is what I'm seeing outside PB Applications the norm for Windows behavior, or is PB the norm for Windows behavior?

    Is it possible to force those hotkey characters to behave as they are in other applications?
    Adam Drake
    Drake Software

  • #2
    The norm for Windows behavior is a system setting you make thru Control Panel.

    Let me see if I can find the sequence, IIRC it's really buried... nope I can't find it anymore. NOt even using Windows' help. Maybe you'll have better luck finding it.
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      Also, what you are seeing in those apps may not be a top-level menu. It could be some type of menubar control or even a toolbar.
      Dominic Mitchell
      Phoenix Visual Designer
      http://www.phnxthunder.com

      Comment


      • #4
        Adam,

        You can use buttons or picture buttons in place of Menu or do you have to have menu? This way, user can press or click hot key of button and then a drop down type dialog has your menu options(which
        also have hot keys). You create drop down looking menu(dialog) in a Sub and callback. The callback has label which is followed by hidden button(-1,-1,-10,-10) etc.. Also you can have "tooltips" and "context" help. This is all possible thanks to your post about how to execute a label.

        Brent

        Comment


        • #5
          I use:

          Code:
          'show keyboard accelerators
          SendMessage CBHNDL, %WM_UPDATEUISTATE, _
          MAK(LONG, %UIS_CLEAR, %UISF_HIDEACCEL OR %UISF_HIDEFOCUS), 0
          I have to insert it in the %WM_INITDIALOG handler for each dialog.

          Comment


          • #6
            Win2k, WinXP (Vista?):
            Display Properties/Appearance/Effects - Hide underlined letters for keyboard navigation until I press the Alt key.
            On by default!

            This setting can be overcome by %WM_UPDATEUISTATE to an extent (Adam himself refered to this technique in an earlier discussion..
            http://www.powerbasic.com/support/fo...ML/012914.html )
            Code:
                Case %WM_INITDIALOG
                  Dialog Post CbHndl, %WM_USER + 1000, 0, 0
                Case %WM_USER + 1000
                  Dialog Post CbHndl, %WM_UPDATEUISTATE, MakLng(%UIS_CLEAR, %UISF_HIDEFOCUS Or %UISF_HIDEACCEL), 0
            That will "change the user interface (UI) state for the specified window and all its child windows" i.e. reveal focus
            indicators and keyboard shortcut cues eg. in button text (E&xit = Exit) etc.
            Unfortunately it doesn't reveal the cues in menu text.

            This clunky fix does seem to work with the menu cues too..
            Code:
                Case %WM_USER + 1000
                  KeyBd_Event %VK_Menu, 0, 0, 0: Sleep 1
                  KeyBd_Event %VK_Menu, 0, %KEYEVENTF_KEYUP, 0: Sleep 1
            Another option could be to use OwnerDrawn Menus? Bernard Ertl posted an example..
            http://www.powerbasic.com/support/fo...ML/001465.html
            - His code does reveal the Menu keyboard shortcut cues independantly of the Display Properties setting but that seems a long way around
            Rgds, Dave

            Comment


            • #7
              The WM_UPDATEUISTATE message does not actually work for showing the menu accelerators when I try it.
              Adam Drake
              Drake Software

              Comment


              • #8
                Adam,

                The problem is that WM_UPDATEUISTATE changes the user interface (UI) state for the specified window and all its child windows - but it seems that the menu doesn't act as a child window and is not updated.

                Programatically sending an 'ALT' keystroke to the window only seems to partially work - ie the menu is displayed with accelerators visible but it's not persistant and they are hidden again after the first mouse click. (Though hot keys on buttons etc do stay visible!)

                The apps that you have observed which do always display their menu accelerators may be using ownerdrawn menus?

                Possibly there is a yet to be discovered message equivalent to WM_UPDATEUISTATE that informs the menu what the current UI state for the window is?
                (Sadly redrawing the menu bar with MENU DRAW BAR CbHndl doesn't do it!)
                Rgds, Dave

                Comment

                Working...
                X