Community
Participate
Working Groups
in I200312020950 Alt+Enter no longer shows me the properties of a file.
Which key configuration? Default? Or "Standard (3.0)"?
either... in both cases the net effect is the same!
If I select a file and press "Alt+Enter" the file opens in the editor (using the default key configuration). Is this the same behaviour you're seeing?
yes.... if the file is already open nothing much happens except focus going to various different places. The confusion might be due to the fact that when you press Alt the menus become active....
Chris, I believe this is a problem with how contexts, activites and the command manager are playing with each other. When "ALT+CR" is pressed, WorkbenchKeyboard finds the following: commandId="org.eclipse.ui.file.properties", action=ActionHandler(RetargetAction("org.eclipse.ui.file.properties")), and action.isEnabled=false. Further inspection with a debugger indicates that the RetargetAction still believes that a TextEditor has focus. In actuality, the PackageExplorerPart has focus. This is probably why it is responding that it is disabled. The PackageExplorerPart then receives the key event, which it (for some reason) decides means the selected object should be opened.
This problem has some similarities to Bug 48024 -- fixing one might fix the other.
sending this back to you.. 1. contexts and activities aren't at play. there should be real evidence of that before you send a bug to me for that reason. this isn't a catch-all to make me take a key binding bug. 2. assign a key, say 'F4', to File->Properties. it works fine. 3. to make sure customization itself isn't fixing the problem, change the plugin.xml to a unused keystroke not containing 'CR'. (i used 'ALT+F12'). it works fine. 4. i agree that the TextEditor is the active part in your case. i beleive the problem is that somehow 'CR' is coming through causing the selection to open. part selection changes, and the 'ALT+CR' then comes through. pick something without an internal editor - like an .HTML file - notice 'ALT+CR' opens the html file in a browser AND opens the properties dialog (because in this case, part activation didn't change to an internal editor).
SWT: This is another bug which I'm seeing problems on, and a fix would be nice for M6 (maybe required). I see the problem only on Windows, and it has to do with event ordering. Basically, the widget is processing the event before our key filter on display gets it. Here is a clip of some debugging output to show the weird interleaving. Sorry if it's hard to read. The order of events is: we received "Alt" down, tree receives "Alt" down, tree receives default selection, we receive "Alt+CR" down. globalKeyFilter receives KeyDown event: keyCode=0x10000; stateMask=0x0; character=0x0 Tree receives KeyDown event: keyCode=0x10000; stateMask=0x0; character=0x0 Tree receives default selection event globalKeyFilter receives KeyDown event: keyCode=0xd; stateMask=0x10000; character=0xd Now, this behaviour is different then what we'd been seeing before. First of all, is "Alt+CR" supposed to trigger a default selection? Second, do default selection events precede our key filter (we are listening for KeyDown and Traverse)?
I know about this one. Basically, we need to process Alt+<key> in order to find out whether it is a mnemonic.
I was completely wrong. It's an ordering problem (like Doug said). We issue the event from WM_CHAR and the tree looks for default selection and issues the event in WM_KEYDOWN.
Fixed > 20031212 Doug please retest to confirm. Thanks.
Steve: I'm trying I200312151413, and the bug still exists.
Here is the test code I used: import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; public class PR_47973 { public static void main (String[] args) { Display display = new Display(); Shell shell = new Shell(display); Tree tree = new Tree (shell, SWT.NONE); tree.setSize (200, 200); new TreeItem (tree, SWT.NONE).setText ("Item"); tree.addListener (SWT.KeyDown, new Listener () { public void handleEvent (Event event) { System.out.println ("KEY"); event.doit = false; } }); tree.addListener (SWT.DefaultSelection, new Listener () { public void handleEvent (Event event) { System.out.println ("DEFAULT"); } }); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } }
Can you try out the code?
Sorry, it appears to be fixed in I200312160800. Perhaps the SWT map file wasn't updated in time for I20031215?
