Summary: | [Browser] Display.addFilter, MenuItem.setAccelerator, SWT.KeyDown inconsistencies | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Christophe Cornu <christophe.cornu+eclipse> |
Component: | SWT | Assignee: | Grant Gayed <grant_gayed> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | duongn, steve_northover |
Version: | 3.1 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Christophe Cornu
2005-03-08 12:12:23 EST
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. |