You are here

Using keyboard to get a (context) menu

7 posts / 0 new
Last post
Martin0815
Martin0815's picture
Offline
Last seen: 6 years 6 days ago
Joined: 2009-12-19 15:28
Using keyboard to get a (context) menu

Hi,

I use the PortableApps Platform since years and since years mostly with the keyboard.
Since ever I can remember, the menus and the context menus open, if initiated with the keyboard, at the position of the mouse pointer, not at the position of a list item of the apps list, not at the position of the "Apps", "Backup", "Options", etc. "menu buttons".

Please consider to change the position of the menus opened using the keyboard, to be context, not mouse pointer related.

Thanks in advance!

Best regards,

Martin

Martin0815
Martin0815's picture
Offline
Last seen: 6 years 6 days ago
Joined: 2009-12-19 15:28
Such a simple code change needed, but nothing …

I'm still annoyed using the start menu with the keyboard.

Raising the start menu with Ctrl+Alt+Space, pressing Alt+A opens the "context" menu for "Apps". But it opens somewhere on the desktop, where the mouse is. The change in the source code should be simple, asking the related control, which opens the "context" menu by clicking, for its window rect and use left-bottom coordinate to open the "context" menu. The OS cares for opening in a way, that it won't cross display borders. Since clicking with the mouse on to such an interactive element like "Apps" or "Backup" raises the "context" menu at the coordinates of the mouse cursor, too, this behavior should be considered to be changed at all.

In the windows world it is a good practice to open menus like these at coordinates related to the UI they belong to.

The needed change is minimal and gives a constant user experience.

Martin Lemburg, Berlin / Germany

John T. Haller
John T. Haller's picture
Offline
Last seen: 3 hours 30 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Not Quite

When you use keyboard controls, you're not using the visible buttons on the menu. The visible buttons on the menu are not buttons. They are a series of two images and a text control, none of which can receive focus to respond to keyboard inputs. A series of hidden standard buttons are used off screen to handle keyboard controls. The change will require custom coding per button for the 33 buttons on the menu.

Sometimes, the impossible can become possible, if you're awesome!

Martin0815
Martin0815's picture
Offline
Last seen: 6 years 6 days ago
Joined: 2009-12-19 15:28
Okay. I'm working in a

Okay. I'm working in a VisualStudio World since years. An all Win32 applications have the possibility to map command IDs to accelerators (keyboard short cuts, hot keys, …) in the resources.

If the pa start menu is visible and has the focus, it could receive WM_COMMAND messages for defined accelerators (in the resources).
It only needs a WM_COMMAND handling for the defined accelerators in its WindowProc or a OnCommand handler (MFC, windows messages map).
In the handler for WM_COMMAND, only those accelerators need special handling, where those act like a menu button opening a kind of cascading sub menu. For those the position of the "cascading sub menu" needs to be calculated independent of the mouse pointer.
If the applicaiton (pa start menu) is HDPI aware, than those calculations may need the DPI of the current display to get the right coordinates.
BTW - I have a multi monitor setup and if the mouse is on the secondary and the pa start menu on the primary, the "cascading sub menu" gets visualized on the secondary monitor.
This not really wanted, is it?

Is the usage of Win32 resources, accelerator tables in the resources possible?

Martin Lemburg, Berlin / Germany

John T. Haller
John T. Haller's picture
Offline
Last seen: 3 hours 30 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Not Visible

As mentioned in my above comment, the actual buttons that are receiving focus when you use keyboard input are not visible on the screen. They are on the form but about 300px to the right of the visible area (clipped because the form is smaller than their positions). As such, they can't be used as the origin of a context menu. I must manually calculate it based on the associated pseudo-controls (two images and a label) that are visible as buttons in the menu and appear to have focus as you move around (by swapping an image in to make it appear highlighted). If the menu used regular buttons, I wouldn't need to do this, but regular buttons look like buttons and not menu items.

Sometimes, the impossible can become possible, if you're awesome!

Martin0815
Martin0815's picture
Offline
Last seen: 6 years 6 days ago
Joined: 2009-12-19 15:28
Since I do not know, the

Since I do not know, the environment you develop in, I don't know, if the suggestion with the Win32 resources and the accelerator tables inside the resources would be applicable at all.
In our C++ environment, we do not need hidden buttons to simulate getting the keyboard focus, but use the mentioned accelerator definitions from the Win32 resources of the executable.
Thus the command handler or the WindowProc function handles the incoming WM_COMMAND messages triggered by the defined accelerators, like Alt+A, Alt+O, etc.
On startup you could fill an array/list of vier elements with the coordinates of the four "menu buttons", the left-bottom image/text rectangle point.
In the WindowProc function (e.g.) only the command IDs for Alt+B (Backup), Alt+A (Apps), Alt+S (Search), Alt+H (Help) accelerators would be affected and would use the 0 to 3rd element in the array above (filled on startup) for opening the "cascading sub menu".
If the pa start menu is DPI aware, than a change of the DPI (WM_DPICHANGED message) would need an update of the 4-element array of points.

Okay - no matter how you implement pa start menu, please ensure in some way, that the opened menu are "near" to the UI element, associated with this menu. No more menu on another monitor after pressing e.g. Alt+A, only because the mouse there, would be really appreciated.

Martin Lemburg, Berlin / Germany

John T. Haller
John T. Haller's picture
Offline
Last seen: 3 hours 30 sec ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Added To The List

It's been added to the list of known issues and may be addressed in a future release:
https://portableapps.com/node/28593

Sometimes, the impossible can become possible, if you're awesome!

Log in or register to post comments