Bugzilla – Full Text Bug Listing
| Summary: | [Viewers] ITreeViewerListener on Tree component reports incorrect expansion state | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Rajeev Sudra <rajeev> | ||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | Keywords: | helpwanted | ||||
| Version: | 3.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Rajeev Sudra
Created attachment 26906 [details]
UI Test to expose the problem
The attachment is a standalone swt application that exposes the problem.
After running the program, selected "choose root folder" and choose a location
in your file system that contains more than one directory.
The Tree should render the collapsed directory structure.
Expand the top node. An ITreeViewerListener is attached which will print all
the expanded nodes followed by "-------------------" to show it has finished.
It will show no expanded nodes.
Select "invoke after expansion" which will print all expanded nodes, this time
outside of the execution of the listener above. This time the expanded node
will be printed to the console.
I'm pretty sure this is a dup of bug 59941 but I'm moving to UI because of the JFace code. Note that the operating systems update the expanded state of the node after the notification has been issued so this should be WONTFIX. The contract for the interface suggests that the event has aready occured (and is worded as such). Either the interface should be changed to suggest that the event is in pre/mid transaction (so don't rely on the expanded state of the item) or the event is fired after the operating system updates the expanded state. Given the current situation, how am I supposed to process the TreeItem's state after expanding or collapsing a node in an event driven fashion? During the execution of the listener, I walk the TreeItem's to figure out if I should hide or display editparts that map to child TreeItems of the collapsed or expanded TreeItem. This is a serious limitation in my opinion (but could be address by a pre and post listener for expand/collapse event handling? Or to honour the ITreeViewerListener contract in terms of event dispatching behaviour) There is ambiguity with how it worked before (atleast with the TableTreeViewer and the TreeViewer is suggested as its replacement). Agree? As a workaround, I would suggest spawning an asyncExec which should see the correct expansion state. Hitesh is now responsible for watching bugs in the [Viewers] component area. 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. -- The automated Eclipse Genie. This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag. |