Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 424542

Summary:

[Tree] setSelection does not scroll on creation and on collapsed first level tree items

Product:

[RT] RAP

Reporter:

Lutz Suhrbier <l.suhrbier>

Component:

RWT

Assignee:

Project Inbox <rap-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

ivan

Version:

2.1

Target Milestone:

2.3 M1

Hardware:

OS:

All

See Also:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=419982

Whiteboard:

Attachments:

Description	Flags
TreeViewerScroll in ExpandBar	none

Description Lutz Suhrbier

2013-12-20 11:27:04 EST

Created attachment 238519 [details]
TreeViewerScroll in ExpandBar

The snippet in TreeViewerScroll with ExpandBar attachment uses setSelection to select and scroll to an initially invisible tree element (push set selection button).

Expanding and selecting of the element works, but scrolling to the element will not work initially (If you push on the button first). You'll need to push it twice to scroll.

Manually, you can tweak the intended behaviour by moving the vertical scrollbar a little bit, push the selection button again and wondering why the treeviewer scrolls to intended element now ?

Collapsing all first level tree items (causes the scrollbar to move at the top), and then hitting the button does not scroll also. You'll have to move the scrollbar manually as above.

Pushing the browser's reload button, destroys the layout completely. The tree viewer blows up its initial size, and doesn't respect the given layout and breaks the dimension limits set for the parent composite. The ExpandBar is not visible anymore.

In bug #419982, my initial snippet without an ExpandBar finally worked fine after setting the tree's layoutdata to grab both horizontally and vertically.

Now, it appears like the ExpandBar intercepts something in the layout chain ? Is it a bug, or is there a known turnaround ?

The final solution should further include to assign a TreeColumnLayout instead of GridLayout to the treeViewerComposite, which is introduced as parent composite of the TreeViewer. The Doc says, that in order to define ColumnWeightData or ColumnPixelDate and set it for some tree columns, the TreeViewer must have a parent with TreeColumnLayout set ? 
Do I have to expect further setSelection troubles, if the current bug is fixed and I set the layout to TreeColumnLayout ?

Thanks
Lutz

P.S.: The bug also applies to RAP 2.2 RC1


Best regards
Lutz

Comment 1 Ivan Furnadjiev

2013-12-20 14:44:57 EST

Lutz, please check your Tree (parent Composite) GridLayout data. Make sure that the Tree (TreeViewer) is not left to it's preferred size.

Comment 2 Lutz Suhrbier

2013-12-21 11:09:50 EST

Ivan,

could you please clarify a little bit what you want to suggest me ?

Do you mean, that should use the hint() function to set a fixed layout size for the treeviewer ?
If so, why can I not leave it to its preferred size ? What size should I set, if not the preferred size of the treeviewer ?

I am a little bit confused, even more as your tip bug in #419982 suggested to set both grab() values to true, which finally means, that the tree will size to its preferred size, or not ?

best regards
Lutz

Comment 3 Ivan Furnadjiev

2014-01-06 05:35:31 EST

Hi Lutz, sorry for the late response - I was in vacation. In order to avoid broken layout on page reload remove the layout from the ExpandBar. Setting layout on ExpandBar does not make sense both in SWT and RAP. About the scrolling issue you are right. There is still bug related to set top item index and create/expand item in the same server response. As item is created/expanded on the client after applying the top item index it's possible the top index to be ignored (invalid at that point - bigger than actual visible items).

Comment 4 Ivan Furnadjiev

2014-01-14 05:30:33 EST

Fixed with change https://git.eclipse.org/r/20503