Community
Participate
Working Groups
What is the expected order for KeyDown coming from Display.addFilter, related MenuItem accelerator event and SWT.KeyDown emitted by a widget? Case 1 - show that MenuItem.setAccelerator and Display.addFilter must not be mixed 1. Run snippet below on Windows 2. Give focus to text widget (left side) 3. Press CTRL N Result: Display KeyDown character keyCode 262144 menuitem accelerator Interpretation: Display.addFilter emitted KeyDown for the CTRL keydown. Menu item accelerator was fired when the N keydown was pressed. Display.addFilter never emitted KeyDown for the N. This means the menu item accelerator wins over someone trying to use Display.addFilter to fake accelerators. If no menu item accelerator is set, Display.addFilter fires the expected 2 keydown events: Display KeyDown character keyCode 262144 Display KeyDown character keyCode 110 Case 2. Show that OLE/ActiveX fires too many Display.addFilter events 1. Run snippet below on Windows 2. Give focus to Browser widget (left side) 3. Press key 'f' Display KeyDown character f keyCode 102 Display KeyDown character f keyCode 102 Browser KeyDown character f keyCode 102 There should only be one Display KeyDown event. The results are the same even if the Browser widget does not handle the TranslateAccelerator callback from MSHTML. Veronika: how can we test this on an activeX either than IE? Here are the stack traces for each of these events: Display KeyDown character f keyCode 102 java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1064) at PRBrowser$1.handleEvent(PRBrowser.java:13) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:777) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:841) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:866) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:851) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:879) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:875) at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1181) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:3121) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3024) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1624) at org.eclipse.swt.ole.win32.OleFrame.getMsgProc(OleFrame.java:214) at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:2071) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2522) at PRBrowser.main(PRBrowser.java:42) Display KeyDown character f keyCode 102 java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1064) at PRBrowser$1.handleEvent(PRBrowser.java:13) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Display.filterEvent(Display.java:777) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:841) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:866) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:851) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:659) at org.eclipse.swt.browser.Browser$1.handleEvent(Browser.java:178) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:842) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:866) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:851) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:879) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:875) at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1181) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:3121) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3024) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1624) at org.eclipse.swt.ole.win32.OleFrame.getMsgProc(OleFrame.java:214) at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:2071) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2522) at PRBrowser.main(PRBrowser.java:42) Browser KeyDown character f keyCode 102 java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1064) at PRBrowser$3.handleEvent(PRBrowser.java:35) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:842) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:866) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:851) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:659) at org.eclipse.swt.browser.Browser$1.handleEvent(Browser.java:178) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:842) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:866) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:851) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:879) at org.eclipse.swt.widgets.Widget.sendKeyEvent(Widget.java:875) at org.eclipse.swt.widgets.Widget.wmChar(Widget.java:1181) at org.eclipse.swt.widgets.Control.WM_CHAR(Control.java:3121) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3024) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3466) at org.eclipse.swt.internal.win32.OS.DispatchMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.DispatchMessage(OS.java:1624) at org.eclipse.swt.ole.win32.OleFrame.getMsgProc(OleFrame.java:214) at org.eclipse.swt.internal.win32.OS.PeekMessageW(Native Method) at org.eclipse.swt.internal.win32.OS.PeekMessage(OS.java:2071) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2522) at PRBrowser.main(PRBrowser.java:42)
Snippet: import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.browser.*; public class PRBrowser { public static void main(String[] args) { Display display = new Display(); display.addFilter(SWT.KeyDown, new Listener() { public void handleEvent(Event e) { System.err.println("Display KeyDown character "+e.character+" keyCode "+e.keyCode); Thread.dumpStack(); } }); Shell shell = new Shell(display); Menu bar = new Menu(shell, SWT.BAR); MenuItem item = new MenuItem(bar, SWT.CASCADE); item.setAccelerator(SWT.CONTROL | 'n'); item.addListener(SWT.Selection, new Listener(){ public void handleEvent(Event e) { System.out.println("menuitem accelerator"); } }); item.setText("My Menu"); shell.setMenuBar(bar); shell.setText("PRBrowser"); shell.setLayout(new FillLayout()); Text text = new Text(shell, SWT.NONE); Browser browser = new Browser(shell, SWT.NONE); browser.addListener(SWT.KeyDown, new Listener() { public void handleEvent(Event e) { System.err.println("Browser KeyDown character "+e.character+" keyCode "+e.keyCode); Thread.dumpStack(); } }); browser.setText("<html><body>Hello</body></html>"); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } }
About Case 2: The extra Display.addFilter keydown event is coming from notifyListeners invoked in the Browser widget for each keydown: case SWT.KeyDown: case SWT.KeyUp: { notifyListeners(e.type, e); break; So that could be a problem for every custom widget?
Vikki and SN to understand the problem and fix it. I thought that we saw this once already when hacking the original "allow key in embedded controls" fix.
This is almost certainly fixed. The order is that accelerators come first, then filters, then key down to a widget. In OLE, by definition, the current order is accelerators, OLE control, filters, then key down. This is the correct way that keys are processed for OLE, but there was some talk of overriding this to let filters and key down run before the OLE control. It's not clear that this is even possible. Grant to verify that the browser part of this bug is fixed and close.
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. If you have further information on the current state of the bug, please add it. 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.
