Community
Participate
Working Groups
Build 200303272130 The table tree viewer uses ITreeContentProvider.getElement() to access the raw children. Tree Viewer uses ITreeContentProvider.getChildren(). Shouldn't use table tree getChildren as well
For both TreeViewer and TableTreeViewer, it uses getElements for the top-level elements, and getChildren for child elements (and children of child elements, etc.). See AbstractTreeViewer.getRawChildren.
Chris, Nick is right. Do you still have the code we looked at at code camp. I am wondering what the problem is since I am pretty sure that we ended up in the getRawChildren() method of the structured viewer for the table tree viewer instance.
Created attachment 4971 [details] Demonstrate drill down problem when returning the root element in ITreeContentProvider>>getElements() In the target workspace show view Metrics>>Metrics Table View and click on any IJavaElement in the Package Explorer. This should show some values in the view. I want the selected element to be presented in the view: public Object[] getElements(Object inputElement) { // return getChildren(inputElement); return new Object[] {inputElement}; } Now when you drill down in the hierarchy you always get the root element.
In TableTreeViewer>>getRawChildren you find if (equals(parent, getRoot())) return super.getRawChildren(parent); It gets the children in StructuredViewer>>getRawChildren with result = cp.getElements(parent); I must admit that at a second glace it works exactly like in the TreeViewer. So if it is not a bug I would say it is a design flaw that you don't allow the user the have the root element presented. To explain what I want I attached the code from the camp.
In general, viewers do not handle multiple equal elements well. For example, the internal map from model element to SWT item is a simple map, from one model element to one item. This is another case. It would be better not to case on the root element. Reopening the PR so that this can be addressed in the future. Reducing severity and priority though.
Isn't that now a duplicate of bug 9262? (both are quite old :(
Yes, thanks. *** This bug has been marked as a duplicate of 9262 ***
