Community
Participate
Working Groups
Eclipse 3.4 M5 - Start Eclipse - Create a java project. - Create a test class, with a dummy main() method. - Try to launch it using Alt+Shift+X, J. - It doesn't work. The keybinding is ok because Alt+Shift+X shows the little popup. The problem is with command handling. If you click the drop-down "Run" menu in the launch action set, and them try the shortcut again, it starts to work. The same if you right click something that displays the "Run As", "Debug As" action set in context menu.
The underlying problem is that the debug plugins are not loaded yet, so when you activate the action handler nothing happens (although the SDK does know about the key combination). CC'ing Paul to see if he has any insight to a solution
For "ALT+SHIFT+X, J" we're trying to execute org.eclipse.jdt.debug.ui.localJavaShortcut.run Mike, is it that the handler for this action is being provided programmatically somewhere? Is it through an actual call to handlerService.activateHandler(*) or is it using one of the legacy mechanisms? PW
Its not pretty, but here it goes: 1. we have a command defined using the org.eclipse.ui.commands extension 2. we have a binding defined (for the alt+shift+x, J) using the org.eclipse.ui.bindings extension 3. in the backing class for the IConfigurationElement for a defined launch shortcut (LaunchShortcutExtension) we get an IHandlerService instance from the workbench and register the binding / command to execute the launch shortcut (in LaunchShortcutExtension#registerLaunchCommandHandlers()), using a call to handlerservice#activateHandler(..). so it appears as though none of this will happen if the debug plugins are not loaded, but the the workbench still knows about the keybinding from our contribution (in plugin.xml)? Does that help?
The problem you're trying to solve is loading ... when you use a keybinding it executes the command which delegates to its handler. If the handler is contributed through plugin.xml, we have a HandlerProxy and execution forces loading so it all works. 3 ways come to mind, but they all require changes of some kind. 1) define one command per mode (run, debug, profile) that each take the launch short cut id as an optional parameter. Give each command a default handler that uses the parameter to launch the correct launch short cut. Then each keybinding becomes: <key sequence="M2+M3+X J" commandId="org.eclipse.debug.ui.localShortcut.run" schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"> <parameter id="org.eclipse.debug.ui.localShortcut.id" value="org.eclipse.jdt.debug.ui.localJavaShortcut" /> </key> Requires the client to re-write their keybindings and get rid of their command. The downside also includes that the command is either enabled or disabled ... you could make the menus items visible or invisible depending on if they were applicable, but you would not be able to show them as some enabled/some disabled. 2) provide a default handler for clients to use that is also an IExecutableExtension. The clients keep their own command and add a defaultHandler clause that looks like: <defaultHandler class="org.eclipse.debug.ui.LocalShortcutHandler"> <parameter name="org.eclipse.debug.ui.localShortcut.id" value="org.eclipse.jdt.debug.ui.localJavaShortcut"> </parameter> <parameter name="org.eclipse.debug.ui.localShortcut.mode" value="run"> </parameter> </defaultHandler> This is still a client side change, but much more localized. It also allows the enablement of different types of "run" shortcuts to be different. 3) Probably the least-change approach is to simply provide a defaultHandler that clients can insert in their commands: defaultHandler="org.eclipse.debug.ui.internal.LocalShortcutHandler" The handler can talk to the existing system (it can access the command id that is calling it using event.getCommand().getId()) Then you can either have it do some of the work or simply act as a placeholder to load up the system which then replaces it (sorta). It still requires a client side change. PW
*** Bug 231220 has been marked as a duplicate of this bug. ***
*** Bug 238872 has been marked as a duplicate of this bug. ***
*** Bug 233619 has been marked as a duplicate of this bug. ***
In bug 233691c6 user claims this problem did not exist in 3.3.
*** Bug 236024 has been marked as a duplicate of this bug. ***
Reg. comment 8- wrong bug number, should be 233619. Same user comment about functionality still working in 3.3 in bug 236024.
This is definitely a (very annoying) regression from 3.3. It was one of the first things I noticed when upgrading to 3.4.
(In reply to comment #11) > This is definitely a (very annoying) regression from 3.3. It was one of the > first things I noticed when upgrading to 3.4. Yes, we fixed some bugs in 3.4 that were eagerly loading the debug plugins (amongst other plugins) ... but this facet of debug only works (at the moment) with the plugins loaded. PW
Option 4: the only way to do this without client changes. You would have to read your relevant extension point and/or scan the commands for you pattern in an early startup plugin. The where is up to you, but it doesn't have to have any real Platform Debug requirements. On startup, activate the same handler, DebugStartHandler, for all the relevant commands. The first time it is executed, DebugStartHandler deactivates itself for all of the commands and then executes the command in question. There would also have to be a hook in there, if debug becomes active deactivate the handlers. From that point on, all commands work the normal way. PW
*** Bug 284924 has been marked as a duplicate of this bug. ***
*** Bug 298303 has been marked as a duplicate of this bug. ***
*** Bug 305107 has been marked as a duplicate of this bug. ***
*** Bug 332820 has been marked as a duplicate of this bug. ***
*** Bug 302257 has been marked as a duplicate of this bug. ***
IT ALSO BE IN 3.6.2 X64 JDK X64.
*** Bug 314856 has been marked as a duplicate of this bug. ***
*** Bug 370257 has been marked as a duplicate of this bug. ***
Eclipse 4.2 20120614-1722 OS X 10.8.1 I also experience this problem using Alt+Cmd+X, T. It's very annoying to resort to use of the mouse.
Eclipse 4.2 20120914-1800 Win32 x86_64 I also experience this problem using Alt+Cmd+X, T. I am looking forward for fix of this issue, because this shortcut is very handy by running unit tests very often (TDD).
I found that you can work around this problem and similar ones by changing the When='In windows' to When='In Dialogs And Windows'.
(In reply to comment #24) > I found that you can work around this problem and similar ones by changing > the When='In windows' to When='In Dialogs And Windows'. Thank you. Your solution is working. I opened: Window > Preferences > General > Keys, then filtered for 'Shift+alt+x' then for each command I changed When field from 'In windows' to 'In dialogs and windows'. The same for 'shift+alt+d' I think the 'shift+alt+d' + <letter> and 'shift+alt+x' + <letter> shortcuts should have When set to 'In dialogs and windows' by default, because after this combination is pressed the small corner dialog pops and gets focused. After that part two of the command (J, C, etc) is ignored because when is set to 'In windows'
Still happens in Eclipse Mars.
The suggested workaround doesn’t work for me with Eclipse Java EE 2019-12-R. In Preferences / General / Keys, at the command Run Java Application (binding Shift+Alt+X J), I set “When” at value “In Dialogs And Windows”, and restart Eclipse. Then I use Shift+Alt+X J on a Java class with main, and nothing happens. When I right-click the project or run something (e.g. with Ctrl+F11), the shortcut works again.
I also doubt this workaround can work. But thanks for bringing up this bug! Would be even better if I had found it before working on bug 553075. I came to the same results as Paul and already tried his option 3 but always ended in some conflicting handler errors. Debug has rather often some startup problems so an early startup plugin to listen for various events to start debug plugin might help for other things as well. I cannot say when I have time for this again so if someone else want to work on this feel free to start.
*** Bug 553075 has been marked as a duplicate of this bug. ***
