Community
Participate
Working Groups
Build Identifier: I20080617-2000 F12 key does not receive SWT.KeyDown or KeyPressed event when used in eclipse's plugin environment. It works fine if used as a java Application. Similar behaviour is observed for F10 Key. Reproducible: Always Steps to Reproduce: 1. Use the F12F10SWTBug.zip to form an eclipse plugin project. 2. Test this plugin by using "Eclipse Application" from Debug/Run Configurations. (Eclipse Application should be configured to run org.eclipse.ui.ide.workbench application) 3. Once the eclipse Application is started, go to Window->Show View->Other-> Sample Category -> F12 F10 SWT Bug 4. Once the application is started, its text area displays the Key event recieved. Note that pressing F12 on buttons does not recieve SWT.KeyDown and KeyPressed events. Similarly for F10 Key.
Created attachment 164955 [details] Plugin project zip file containing source code for recreating this bug
SWT is sending the key events. The workbench has a display filter the changes the event type to SWT.None.
F10 opens the left most (File) menu. F12 activates the open editor. These are being processed by the keybindings filter (Keys preference page) first. PW
Is there a way to overwrite the Keybindings?
(In reply to comment #4) > Is there a way to overwrite the Keybindings? For F12, change the keybinding in the keys preference page. For F10, that is done by SWT and cannot be changed. If you add a menu bar to your SWT only snippet, you'll see you no longer get F10 events at all. PW
(In reply to comment #3) > F10 opens the left most (File) menu. F12 activates the open editor. > > These are being processed by the keybindings filter (Keys preference page) > first. > > PW Is this the correct behaviour?? Shouldn't it be like this: Window which has the focus should get all the events which it has registered for. Also, once such application is deployed how are we expecting an end user to know that his/her F12/F10 keys are not working because they are being filtered by environment's key binding filter. Here is an example: We have a product which emulates Host Screen and is in the form of an OSGI container. It is developed on eclipse. Now, if a user wants to send F12 key to the host he would not be able to do so because F12 key doesn't work because it is being consumed by the eclipse's Key binding filter instead of the application window which is in focus.
(In reply to comment #6) > Also, once such application is deployed how are we expecting an end user to > know that his/her F12/F10 keys are not working because they are being filtered > by environment's key binding filter. Because your application is responsible for its keybindings. If you use the default scheme, then you will consume F12. Publish that. If you don't want F12 to mean activate editor, then you need to use your own scheme, not the default scheme. Check out the keybinding extension point description for more information. This should only be a problem if you are starting up the Workbench (org.eclipse.ui), not if you deploy a bundle in OSGi. F10 should have an immediately obvious action (jumping to the menu bar and activate the File menu). But this should only be a problem if you have an SWT Menu bar. Do you? The only way I can think of to work around F10 is the way that something like vnc does: Pick a keybinding that will pop up a menu. That menu can send that key as well as F10 through your host screen. The other option is to re-open this bug as an enhancement request against SWT to provide API to allow F10 to be overridden. That could be looked at in 3.7. PW
(In reply to comment #5) > For F10, that is done by SWT and cannot be changed. If you add a menu bar to > your SWT only snippet, you'll see you no longer get F10 events at all. Paul, I was not able to confirm the above: public static void main(String[] args) { Display display= new Display(); Shell shell= new Shell(display); shell.addListener(SWT.KeyDown, new Listener() { public void handleEvent(Event e) { System.out.println("KeyDown " + e.keyCode); } }); shell.addListener(SWT.KeyUp, new Listener() { public void handleEvent(Event e) { System.out.println("KeyUp " + e.keyCode); } }); Menu menu = new Menu(shell, SWT.BAR); shell.setMenuBar(menu); MenuItem item = new MenuItem(menu, SWT.CASCADE); item.setText("File"); shell.setSize(300, 300); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } Note that F10 is received by the listener, after that focus moves to the first menu item (which will show in blue). With the menu item blue press another key down, this key down is lost, the menu loses focus. You can prevent the OS from changing to focus to the menu during f10 by setting doit=false in the event handler.
(In reply to comment #8) > (In reply to comment #5) > > For F10, that is done by SWT and cannot be changed. If you add a menu bar to > > your SWT only snippet, you'll see you no longer get F10 events at all. > > Paul, I was not able to confirm the above: With your snippet, I get KeyUp (but no KeyDown on linux). If I add items under File, then I no longer get any KeyDown or KeyUp Menu file = new Menu(item); item.setMenu(file); new MenuItem(file, SWT.PUSH).setText("One"); new MenuItem(file, SWT.PUSH).setText("Two"); new MenuItem(file, SWT.PUSH).setText("Three"); PW
> With your snippet, I get KeyUp (but no KeyDown on linux). > > If I add items under File, then I no longer get any KeyDown or KeyUp > > Menu file = new Menu(item); > item.setMenu(file); > new MenuItem(file, SWT.PUSH).setText("One"); > new MenuItem(file, SWT.PUSH).setText("Two"); > new MenuItem(file, SWT.PUSH).setText("Three"); > > PW (In reply to comment #7) > (In reply to comment #6) > The other option is to re-open this bug as an enhancement request against SWT > to provide API to allow F10 to be overridden. That could be looked at in 3.7. > > PW Thank you Paul, defining the new key binding for F12 key using org.eclipse.ui.bindings extension point works fine for F12 key. But the issue with F10 key still remains, and I was also able to confirm the above i.e. No key event received when your application have a SWT Menu bar. Going by your suggestion I am re-opening this bug as an enhancement request in SWT component. Bhanu
(In reply to comment #10) > > PW > Thank you Paul, defining the new key binding for F12 key using > org.eclipse.ui.bindings extension point works fine for F12 key. But the issue > with F10 key still remains, and I was also able to confirm the above i.e. No > key event received when your application have a SWT Menu bar. > Going by your suggestion I am re-opening this bug as an enhancement request in > SWT component. > Bhanu Which platform and eclipse build are you seeing this problem? I believe we fix the problem Paul mentioned above (comment#9) on Linux (see bug#316329).
(In reply to comment #11) > (In reply to comment #10) > > > PW > > Thank you Paul, defining the new key binding for F12 key using > > org.eclipse.ui.bindings extension point works fine for F12 key. But the issue > > with F10 key still remains, and I was also able too confirm the above i.e. No > > key event received when your application have a SWT Menu bar. > > Going by your suggestion I am re-opening this bug as an enhancement request in > > SWT component. > > Bhanu > > Which platform and eclipse build are you seeing this problem? I believe we fix > the problem Paul mentioned I am able to recreate the problem using eclipse 3.6.1 on linux. The sample used to recreate the problem is there in comment#8, with a modification of adding a menu item under the"file"menu. The problem is that no key down or key up events are received by the listener when F10 key is pressed, as mentioned by Paul in comment#9. While on windows, only key released event is received. Bhanu.
bug#316329 was only fixed in 3.7 M2. Please try that build.
(In reply to comment #13) > bug#316329 was only fixed in 3.7 M2. Please try that build. Thank you Silenio. I verified with 3.7, the listener was now able to get KeyDown events. Also, noticed that still no KeyUp event for F10 and the focus goes on to the menu bar's first menu item. I guess this behaviour can be changed by overriding the OS's key binding for F10. Bhanu.
Closing as per comment 14.
