Community
Participate
Working Groups
We have a filesystem explorer... eg. a Tree control on the right with a results panel on the left... above the results view, we have an editable combo control... it's for typing in a path... that we would then find and select in the tree and results panel (assuming the path exists). If we select a spot in the tree then this dropdown will pre-populates with the path represented by the tree selection. In prior eclipse we can type in additinal chars and we listen for the \r to tell us the user is done. We then use Combo.getText() and send the tree selection to that spot... the problem is that now, anything typed in after the pre-selected tree location gets lost and getText only returns the string derived from the initial selection. in our tree... This "worked" as expected in 4.2.0 and 3.x... 4.2.1 doesn't work so well. Is there some default behavior that changed? And this conclusion seems to be the case on both Windows XP and Linux GTK.
... or did some default change and I just need to add an SWT... param?
If I have a path selected in the combo box say: /path/to/some/place And I delete /place, then it does "the right thing" and Combo.getText() returns /path/to/some So the combo does pick up and set that change somehow.
I believe there are no changes in SWT between 4.2.0 and 4.2.1 that could cause this to happen. There are some changes in GTK Combo.java, but they are unrelated. There are no changes in Windows at all. It seems like from your description that the Combo is selecting the text when it gets focus and if you type the selection is removed. Here is a snippet that does something similar. When I click on the text field, the combo text is set and given focus. I run this on Windows and GTK with both 4.2.1 and 4.2.0 and the all behave the same. But that is expected behavior. Could you provide a Snippet that reproduces your problem? import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; public class Snippet24 { public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); shell.setLayout (new RowLayout ()); final Combo combo = new Combo (shell, SWT.NONE); combo.setItems (new String [] {"A-1", "B-1", "C-1"}); Text text = new Text (shell, SWT.SINGLE | SWT.BORDER); text.setText ("some text"); combo.addListener (SWT.DefaultSelection, new Listener () { public void handleEvent (Event e) { System.out.println (e.widget + " - Default Selection"); } }); text.addListener (SWT.MouseDown, new Listener () { public void handleEvent (Event e) { combo.setText("Selected TExt"); combo.setFocus(); System.out.println (e.widget + " - Default Selection"); } }); shell.pack (); shell.open (); while (!shell.isDisposed()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } }
Hi, I did try to get a simple code case that shows the problem but I really never got that far. Here is what I do know: We have a perspective and on the left is a tree view (i.e. filesystem navigator) and on the right is the "results view" i.e. directory contents. This view also contains our combo box. The views do have selection change listeners so that when a tree item is selected the path is pasted into the combo box and the location is then selected in the results view. Here is what happens. Eclipse 4.2.0, Current CTE/CCRC code (debug session). I set a selection in the tree and the path is pasted in the combo box, and the folder in question is shown and selected in the results sheet (recall combo and results sheet in same view). The combo box has a keyListener and if I type a path we listen for the \r key (carriage return) and do nothing until the \r key is pressed. Once this key is pressed, we get the text out of the combo box and set it in a selection event to the tree and results panels. In fact if I set breakpoints in our selection listener and keyListener, the keyListener is hit first on the \r then the selection change events fire. In Eclipse 4.2.1 the EXACT same code in a debug session things occur differently. In this case, when I hit the <cr> the selection change event from the results panel fires (i.e. the VIEW gets a change event) even though the combo box has focus! Then at some point the keyListener on the combo box fires but because the selection event has fired FIRST, the items that are already selected in the tree overwrite the combo box text... I'm quite sure that we don't have a key listener in the view but that's how its acting.
of course that whole thing means that the title of this bug is a bit off...
Ok, so the event ordering changed for you. As far as we can tell there are no changes in SWT between 4.2 and 4.2.1 that could introduce this behavior. Are you using plain SWT? Or do you have jface as well? This is a snippet that tries to implement what you described. It works fine for me. Does it fail for you? import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; public class Snippet24 { public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); shell.setLayout (new GridLayout (1, false)); final Combo combo = new Combo (shell, SWT.NONE); combo.setItems (new String [] {"A-1", "B-1", "C-1"}); combo.setLayoutData(new GridData(GridData.FILL_HORIZONTAL)); final Tree tree = new Tree (shell, SWT.MULTI | SWT.BORDER); for (int i = 0; i < 10; i++) { TreeItem item = new TreeItem(tree, SWT.NONE); item.setText("Item" + i); } tree.setLayoutData(new GridData(GridData.FILL_BOTH)); combo.addListener (SWT.KeyDown, new Listener () { public void handleEvent (Event e) { if (e.keyCode == SWT.CR || e.keyCode == SWT.LF) { String text = combo.getText(); System.out.println ("Text in combo is=" + text); TreeItem[] items = tree.getItems(); for (int i = 0; i < items.length; i++) { if (items[i].getText().equals(text)) { tree.setSelection(items[i]); } } } } }); tree.addListener(SWT.Selection, new Listener () { public void handleEvent (Event e) { TreeItem[] items = tree.getSelection(); if (items.length <= 0) return; combo.setText(items[0].getText()); } }); shell.setSize (300, 300); shell.open (); while (!shell.isDisposed()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } }
Created attachment 222586 [details] trace showing selection change after CR in combo box.
I added the stack trace as an attachment. What it shows is a focus shift when I hit <CR>. You get exactly the same sort of focus shift when you hit <TAB>. I annotated the stack with where our code picks up.
From the stack, CompatibilityView is moving the focus to the tree inside the view. which causes the selection event on the tree. I think the change that is causing this difference in behavior is in UI. Moving to UI for comment.
Eric, is this related to the stack traversal we fixed recently? PW
Same bug. This is already fixed in master. *** This bug has been marked as a duplicate of bug 390924 ***
