Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: Our product utilizes editors with AWT components embedded into them. Since moving to Eclipse 3.4, the delete key pressed event is never received by the AWT text fields. Previously, this event was injected on the AWT Event Queue threat. Eclipse 3.4 only injects the delete key released event on the AWT Event Queue. It appears that SWT processing is somehow "stealing" the delete key pressed event. More information:
We believe that it might have the same cause as 234875. We can see that the delete key is being intercepted by the code referenced here that is new in 3.4: https://bugs.eclipse.org/bugs/show_bug.cgi?id=234875#c7
Moving to UI since the workbench is eating the keydown. I don't think this is a result of an swt change in 3.4 since DEL works for me if I use eclipse 3.3.2 with swt 3.4. When DEL gets eaten in HEAD the stack looks like: - DeleteHandler(AbstractHandler).isHandled() line: 135 returns true - HandlerProxy.isHandled() line: 316 - Command.isHandled() line: 873 - WorkbenchKeyboard.executeCommand(Binding, Event) line: 457 returns true because commandHandled == true - WorkbenchKeyboard.press(List, Event) line: 824 - WorkbenchKeyboard.processKeyEvent(List, Event) line: 882 eatKey = true, event.doit = false - OutOfOrderListener.handleEvent(Event) line: 76
What's going on: The default handlers for cut, copy, paste, and delete simply call the methods of the same name on the control (SWT) or component (AWT/Swing) in focus. Select All works more or less the same way, but with an extra parameter. In this particular case, we're looking at WidgetMethodHandler:delete. cut, copy, paste, and delete won't work for the AWT TextField since it doesn't define these methods. selectAll still works. In 3.3.x there was a bogus retarget action interfering with copy, delete, etc so that it was reporting 1) use the retarget action for delete and 2) I'm not handled. This caused the WorkbenchKeyboard to not eat the keys, and they were passed to the TextField. PW
Created attachment 110333 [details] AWT view
I'm not sure what the best course of action is. Ideally it would be to write the appropriate code the performed the equivalent of JTextField#delete() for an AWT TextField and have that in the WidgetMethodHandler (or it's equivalent). Grant, is this something that looks relatively simple in AWT? Potentially another option is to move the current isEnabled() check to the isHandled() check ... this has the possibility of passing through key presses (CTRL+C) that weren't previously available in other cases (since the keypress won't be eaten if the control in focus doesn't have the corresponding method). As a workaround, you can register your own IHandler for org.eclipse.edit.delete in your view and have it return isHandled() false. That should produce the 3.3.x behaviour. Something like: createPartControl(*) { // ... stuff registerHandlers(); return composite; } public void registerHandlers() { IHandler h = new IHandler() { // method stubs public boolean isHandled() { return false; } }; IHandlerService service = (IHandlerService) getSite().getService(IHandlerService.class); service.activateHandler("org.eclipse.ui.edit.delete", h); } PW
I don't think Delete is one of the keys that uses reflection to invoke api on the focus control (CTRL+A/X/C/V are). Delete was fixed for the Browser by adding a case in the delete key handler to not eat the key if a Browser had focus. So the first two options in comment 5 probably don't apply here (?).
(In reply to comment #6) > I don't think Delete is one of the keys that uses reflection to invoke api on > the focus control (CTRL+A/X/C/V are). Delete was fixed for the Browser by > adding a case in the delete key handler to not eat the key if a Browser had > focus. So the first two options in comment 5 probably don't apply here (?). I think the problem is that while we step outside of this filter for DEL for Text and Combo (bug 54654) and did the same for Browser that DEL is written this way for the swing components (like JTextField) ... although looking at the Swing API, delete(int,int) is available. How can this have ever worked? PW
(In reply to comment #6) > I don't think Delete is one of the keys that uses reflection to invoke api on > the focus control (CTRL+A/X/C/V are). Delete was fixed for the Browser by > adding a case in the delete key handler to not eat the key if a Browser had > focus. So the first two options in comment 5 probably don't apply here (?). At least with Option 2, since the widgets in question don't have a delete() method, DEL will show up as not handled and we won't eat the key press. PW
Created attachment 110941 [details] Handle vs enable v01 This handler is acting as a delegate for widget methods: copy(), cut(), delete(), paste(), and selectionAll(*). If the focus widget doesn't support the method, then this handler should report "not handled". This means the key press will not be eaten by eclipse and will be delivered to the focus widget. PW
Created attachment 110972 [details] Handle vs enable v03 This seems like a reasonable fix would be to have the handler say "If the focus widget doesn't implement copy(), then the copy command is not currently handled" If a command doesn't handle a keypress, then eclipse won't eat it and it will be forwarded to the focus widget (allow it to do its thing, in the AWT case allowing it to work) Well, while this new behaviour makes perfect sense, it changes the semantics of calling these commands through the handler service. ex: before hs.executeCommand("org.eclipse.ui.edit.copy", null) used to throw an NotEnabledException in these few corner cases ... now it will throw NotHandledException. You have to be the fringe case to get bitten by this, and the API already requires you to catch this exception (so hopefully, no surprises). It has no effect on the keybinding behaviour. PW
Released for M20080827-0800 PW
verified in M20080827-2000 PW
