Community
Participate
Working Groups
Currently there is no way to be notified of keyboard events during the time a Menu widget has the focus. As an experiment I tried adding untyped listeners on SWT.KeyDown / SWT.KeyUp to a Menu. Another thing I tried is adding a global listener using Display.addFilter(int, listener). In both cases key events are not received when Menu has focus. What I don't understand is that the Menu used in the Window's Shell (just underneath the title bar) is receiving 'special treatment'. I.e. left/right arrow will switch (but this all happens in the native part of SWT). In our case we need to have the menu not underneath the Shell but at another location (see screenshot). It is implemented as a Toolbar with n items. Each item will open / hide one menu instance when selected. Unfortunatelly not having key events prevents us from showing another menu when left/right is pressed. For that reason, it would be great to allow for an untyped listener to receive SWT.KeyUp events. With this we could provide left/right keyboard navigation for our Menus. If there is a workaround I missed, I'll be happy to try it... Thanks, Elias.
Created attachment 140042 [details] Screenshot
How did you place the menu at the specific location ? Are you using Decoration ? Why do you need the handle key events yourself ? The native key handling isn't good enough for you ?
The problem is is that the the Menu(Decoration shell, SWT.BAR) can only be placed at the top position of the shell. This is not what we want, since we are showing a logo there (see screenshot). The other constructor of Menu only allows for creating of pop-up menus. So as a workaround we have created a Toolbar with for example 3 ToolItems (File, Context Menu, Navigation Menu on the screenshot) underneath the logo. Each of these items shows a pop-up Menu underneath it when selected. So we have 3 individual pop-up menus. With the key events we would hide the current popup menu and shown the next one. Let me know if that explains things. Otherwise I can add a snippet of what we are doing...
Attaching a snippet illustrating the issue. As explained in comment #3, because of the limitation that Menu(shell, SWT.BAR) can only be placed at the top position of the Shell, we are using a regular CoolBar with N separatate pop-up menus (one for each tool item). This allows us to place the coolbar beneath a logo or other widget. However because of the missing key events, there is no way to navigate to a menu to the left or right. As you can imagine, this can be quite annoying when trying to navigate menus by keyboard. Some ideas that would help from our POV: - allowing Menu(shell, SWT.BAR) to be placed anywhere (best) or - reporting key events in the menu, so that we could react programmatically. However one related issue there is how to distinguish a right-arrow press that opens a submenu from a right-arrow press that should go to the next top-level-menu. If there are things I can do to move this forward quickly let me know. I'm gone for the next three weeks, so I'm putting in Christian as CC on behalf of the Riena team.
Created attachment 141239 [details] Snippet illustrating the issue
I'm not 100% sure it is possible to implement this everywhere. Can you use no_trim shell to implement your own custom menu ? (like eclipse implements the content assist). Note: we would need to handle acceleratos, mnemonics, sub-menu, etc.
Initially I was hoping a custom Menu could be avoided. Now I see it would also solve other limitations of the Menu widget, that we are running into, such as setting the background. I have to check with the Riena team if the benefits justify going down this road. Assuming we do this, do you thing it would be possible for Riena to contribute a CMenu to SWT? I envision CMenu being API compatible with Menu and having some extra features like keyboard events and a setable background color.
(In reply to comment #7) > Assuming we do this, do you thing it would be possible for Riena to contribute > a CMenu to SWT? I envision CMenu being API compatible with Menu and having some > extra features like keyboard events and a setable background color. Yes, I think that is possible. Just keep in mind that SWT has to be compatible with older java versions (I believe SWT runs with Java 1.2, so stay away from generic, boxing/unboxing, and all the fancy stuff). We also don't use Interfaces every often (only for Listeners and special cases). See CLabel,CCombo, C-ETC as reference.
> I have to check with the Riena team if the benefits justify going down this road. After discussing this within the Riena team, we concluded that we do not have the resources to implement a CMenu at this time -- i.e. we have to do without key events.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
