Community
Participate
Working Groups
Build 20031216 The key binding for triggering incremental builds is no longer operational in this build. This makes it pretty unusable. Do you have regression tests for key bindings ?
Trying to restore default in key binding preferences did not help either. ctrl-S doesn't work either in Java editor.
Problem occurs in any subsequent sessions. I can provide my workspace if you need it.
See also bug 48486. Philippe has posted his workspace to ott4f under: /teams/Eclipse- Platform/anon/in/48486. Veronika also asks: are you using a French keyboard?
I am using a plain US Keyboard with US win2000 install.
I am seeing this behavior on both my machine (laptop + workstation). Jerome got the same behavior after upgrading to this built. Folks in ZRH saw some of it as well.
From the sounds of things, this is a duplicate of 48486. Please re-open if you feel differently. *** This bug has been marked as a duplicate of 48486 ***
Sorry, I think this is a separate bug. Nick believes that Ctrl+B is not in an action set. Let's make this a separate bug, rather than making Bug 48486 even longer than it already is.
------- From Philippe Mulet 2003-12-16 07:12 ------- I am still using an old workspace which was previously running on 20031211, where I had some key binding issues (different sessions had different problems). But this time around it feels like all key bindings are gone, and I do not get any different behavior from a session to the other. ------- From Nick Edgar 2003-12-16 09:34 ------- What Philippe is seeing sounds more like the original problem reported here, not the problem with action set handlers. It's not working when first started up. He did not say he was switching perspectives. Philippe has posted his workspace to ott4f under /teams/Eclipse- Platform/anon/in/48486.
Created attachment 7185 [details] Philippe's Configuration Details Help > About > Configuration Details
More info: - problem doesn't occur with freshly created workspace - problem doesn't occur when reopening 6 months old workspace
I cannot reproduce using my workspace on Windows XP or Linux-GTK. Currently stalled with infra problems getting Philippe's workspace.
Created attachment 7190 [details] Entry from the .log
I've managed to reproduce the problem using a self-hosted Eclipse inside an I20031211 build with PlatformUI from the head -- using Philippe's workspace. I'll attach listeners and see try to see what's going on.
Do you want some help?
I've managed to track down the problem in gross terms. It is not a problem with SWT nor the key bindings. It is a problem "above" key bindings -- somewhere in the command manager or higher. Listener.handleEvent(type=1,stateMask=0x0,keyCode=0x40000,character=0x0) Listener.handleEvent(type=1,stateMask=0x40000,keyCode=0x20000,character=0x0) Listener.handleEvent(type=1,stateMask=0x60000,keyCode=0x74,character=0x14) WorkbenchKeyboard.press(potentialKeyStrokes=[CTRL+SHIFT+T],dialogOnly=false) WorkbenchKeyboard.executeCommand (commandId=org.eclipse.jdt.ui.navigate.open.type) action=null
Log entry in comment #12 seems unrelated. When emptying log and restarting, no such entry is added again either on startup or when pressing any offending key sequence.
FYI, I managed to finally workaround the problem by following these steps: 1. Close all windows except one that contains the Java perspectives 2. Window->Preferences->Export... 3. Window->Preferences->Restore Defaults 4. Exit/restart workbench 5. Notice that key bindings were working (notably Ctrl+S and Ctrl+B) 6. Window->Preferences->Import... (my saved preferences) 7. Exit/Restart workbench 8. Notice that key bindings were still working
Test case is again "Ctrl+Shift+R" (Open Resource). (Note that the broken key bindings are not restricted to action sets.) A handler is never defined for this command. Compare with a fresh workspace, and a handler is defined.
Even simpler steps to solve the problem: - Close all windows but one - Exit and restart.
However, once you reopen another window, then problem reappears again. Seems like the wrong window is getting the event ?
The key is in the number of windows opened. Any workbench opened with two or more windows can have the effect of "clobbering" handlers. Philippe's workbench was a particularly apparent example because both of his workbench windows opened to the same perspective. This is command management stuff. Chris is aware of the problem, and working on it.
Chris has submitted a fix, and I've verified the fix to work (as near as I can see) on Philippe's workspace. This fix will appear in I200312161600. Could those people seeing the problem please double-check the fix as well? Thank you.
I confirm that this problem is addressed when running my workspace on 20031216:1717. Thanks!
Confirmed as well with I200312162000.
