Menus on a Dialog, Underline Hotkeys Question

[Adam J. Drake]

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?

[Michael Mattias]

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.

[Dominic Mitchell]

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.

[BRENT GARDNER]

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

[Bill Eppler]

I use:

'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.

[Dave Biggs]

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 )

    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..

    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/forums/Forum7/HTML/001465.html

- His code does reveal the Menu keyboard shortcut cues independantly of the Display Properties setting but that seems a long way around

[Adam J. Drake]

The WM_UPDATEUISTATE message does not actually work for showing the menu accelerators when I try it.

[Dave Biggs]

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!)