Community
Participate
Working Groups
I wish I could provide a snippet that is failing. Unfortunately, I am running seemingly the same code in two places in PDE and it is failing in one place. The problem is coming in org.eclipse.pde.internal.ui.wizards.provisioner.DirectorySelectionPage, specifically the handleRemove() function. When it fails, it seems to place dotted lines around the element that should be selected, but does not highlight it. To reproduce: 1. Check out org.eclipse.pde.ui from HEAD of CVS (/cvsroot/eclipse) 2. Place a break point in DirectorySelectionPage in the handleRemove() function. 3. Start a runtime workbench in Debug mode. 4. On the runtime workbench, select Windows > Preferences. Plug-in Development > Target Platform. 5. Click the "Add..." button 6. You will see a table displayed in the new dialog window. Click the "Add..." button to add elements. After adding a few elements, click "Remove" button. The break point should hit and TableViewer.setSelection will get called. Note that the next element in the list does not get selected, but dotted lines encompass it. I tried calling both .setSelection() and .select(). Neither actually selected the object. Please let me know if there is any way I can help debugging this problem.
Is this still a problem?
Created attachment 142379 [details] Modified Snippet0035 to show the behaviour of non-visible selection I think this is still a problem. I am not quite sure if it is the same cause, but in my RCP app I use a TableViewer with EditingSupport and FocusCellManager (including FocusCellOwnerDrawHighlighter), and it seems that selections via setSelection are not working correctly. When the TableViewer's selection is changed programmatically via TableViewer#setSelection() there is no visual feedback of the selection change, but in fact the selection does change. Attached is a modified Snippet035 that shows the behaviour. The change I made was to insert the following codeblock at the end of the constructor Snippet035TableCursorCellHighlighter(Shell shell): ------------------------------------------------- Button button = new Button(shell, SWT.PUSH); button.setText("Next row"); button.addSelectionListener(new SelectionListener() { public void widgetSelected(SelectionEvent e) { int selectionIndex = v.getTable().getSelectionIndex(); int nextIndex = selectionIndex + 1; System.out.println("Moving to row " + nextIndex); if (nextIndex >= v.getTable().getItemCount()) { System.out.println("Last item reached"); } else { StructuredSelection sel = new StructuredSelection(v.getElementAt(nextIndex)); v.setSelection(sel); } } public void widgetDefaultSelected(SelectionEvent e) { } }); ---------------------------------------------- To test this behaviour you can do the following: 1. Run the snippet 2. Click on a cell of the first row 3. Push Button "Next row" some times and watch the console output and the table The consoleoutput shows that the selection is in fact moved to next row respectively, but the table does not give any visual feedback of it. I would appreciate if someone (perhaps Brian or Boris?) can tell me if the described behaviour is caused by this bug, or if I should file a separate bug for my problem.
Created attachment 147969 [details] Modified snippet 058 Select initially and randomly a row that will not be shown as selected (unless it is row 0). Also gives the possibility to select a new row randomly by pressing F5. This row will also not be shown unless it is the same row as before.
I have the problem, too, but only with the 3.5 rcp sdk. In 3.4 it worked. Changed the Snippet 058 by adding a keylistener that selects randomly one of the rows. If the row is selected the first time no visual feedback of the selection appears. If i use the random key again and the same row is selected, than the selection is visible. Also if i select a row randomly that is not shown as selected and then move the selection up or down by cursor keys the new selection is shown. (see attachment...) Greetings, Stefan
Hitesh is now responsible for watching bugs in the [Viewers] component area.
Removed from 3.6. Owners can re-assess. PW
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.
