Community
Participate
Working Groups
M9 build + latest from head - new workspace - new simple project - new file Test.doc - type something in it - Ctrl+S - it has no effect - close the editor and reopen it without saving to see Likewise for Ctrl+F4. This used to work in 2.1. At first I thought this was probably due the change in how we do keybindings, but then I found that in 2.1, other accelerators like Ctrl+Shift+S and Ctrl+Shift+F4 had no effect either (or had a different effect), so it seems to me like this is a problem in the OLE support itself.
I just ran into this bug, and did some digging. Here's what I've come up with. The bug manifests itself as an in-place active document, such as Word (or the app I'm working on) not being able to use accelerators that are provided on the Eclipse-supplied menus, like the File menu. So, for example, Ctrl-S doesn't Save even though the document is dirty. The in-place app is calling OleTranslateAccelerator, as it's supposed to. This should lead to a TranslateAccelerator call inside Eclipse to dispatch the Ctrl-S, but doesn't. I believe this is because the accelerator handle that Eclipse returned from the OleClientSite.GetWindowContext call is NULL, and OleTranslateAccelerator needs to look up the accelerator in the table to figure out the ID to pass to TranslateAccelerator. The in-place app uses OleClientSite.GetWindowContext to get the accelerator table, and that call is returning a null accelerator table because when it sends SWT_GETACCELCOUNT to org.eclipse.swt.widgets.Decorations#windowProc, which calls createAccelerators, which walks all the MenuItem's in the display's menu looking for accelerators. The bizarre bit, and what I think is the bug, is that all of the menu items have an accelerator of 0, meaning no accelerator. A breakpoint after the (item.accelerator != 0) condition in org.eclipse.swt.widgets.Decorations#createAccelerators is never hit. I'm guessing this has something to do with switching from accelerators to bindings for keyboard binding of commands - introduced in 3.1 - but that's a shot in the dark. Hopefully someone who knows more can add some details, or even suggest a workaround.
(Verified this bug exists in 3.2.1)
You are absolutely right. As soon as accelerators were no longer used for key bindings in Eclipse, then their is no HACCEL for OLE to process. I'm pretty sure we hack/fixed this by dispatching the key event to Eclipse. Does it fail in Eclipse 3.3 M5?
I am kinda curious about how the menu item accelerator work. So here's some background: in at least 3.0 and on eclipse uses WorkbenchKeyboard which does a display.addFilter(*) for SWT.KeyDown and SWT.Traverse. But for most menu items that we generate, we still create the item with the binding in the setText(*): Save\tCTRL+S Actually, I thought we were still seeing behaviour where CTRL+S was going through the menu item IAction#run(*) method instead of through the keybinding (I thought SWT/OS was executing the menu item instead of generating a key event). But maybe we were mistaken when we saw that. PW
It doesn't work in 3.3 M5; tested by opening a Word doc with the in-place editor, changing the document and hitting Ctrl-S or Ctrl-W. Nothing happens. With an external process in-place active, the external process has its own message pump that handles messages going to the in-place editor. So Eclipse won't see a WM_KEYDOWN (etc) at all when Word has focus. When the in-place editor is DLL-based (like, say, embedding Internet Explorer), Eclipse's message pump gets the message, and so has a chance to dispatch accelerators. But for servers like Word, the only chance Eclipse has to process accelerators is through OleTranslateAccelerator, and that's only going to work if Eclipse can cook up an accelerator table. The only fix I can think of would be to use the key bindings to calculate the accelerator for each menu item rather than depending on the accelerator value. I expect there are bindings that don't map to accelerator values, but generally, that's not going to be a problem - and where it is a problem, there's nothing you can do about it anyway.
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
