Community
Participate
Working Groups
Build Identifier: I20100608-0911 (This may be a duplicate of Bug 135255) I work for Wind River Systems and this problem occurs in our commercial product. Our Kernel Objects View contributes expandable entries to the Properties View. Some kernel objects contribute some of the same Property View entries as well as additional entries. For instance, KO1 may have property entries A, B, C and D, and KO2 may have property entries B and C. (See attached MS-Word for a progression of screen-shots illustrating this problem.) The problem manifests itself when a Property View entry for one kernel object that does not exist in another kernel object is expanded. When selecting a different kernel object and then returning to the original object the expansion state is lost, i.e. the previously-expanded entry is now collapsed. In cases where a large number of Property View entries have been manually expanded, having to re-expand each of them again can be time consuming. Reproducible: Always Steps to Reproduce: I am unable to find a specific test scenario or use case for this in Eclipse.
Created attachment 178190 [details] Progression of screen captures illustrating the problem MS-Word document containing screen captures illustrating the problem.
Created attachment 178191 [details] Patch to PropertySheetViewer to fix this issue Patch to org.eclipse.ui.views.PropertySheetViewer.java to remember expansion state of Property View entries.
Andre, just checked this out and I've got a few questions: - The expanded list is 'static' but there can be many instances of the Properties View open at the same time. I suspect that this may cause issues in multi-instance scenarios. - Using the text string may also be prone to 'false positives' should two different input sources use the same label (i.e. "Address"), is there any more unique way to determine if it's the same field ? - Finally I tried this out using the 'org.eclipse.ui.examples.readmetool' and the current code doesn't appear to keep track of an entry's expanded state unless it's at the 'root' of the tree. If you check this out into a workspace and run an inner (debug) session then you can create a file of type '.usr' which, when opened, will populate the Outline view with a variety of entries. If you open the Properties view and select one or more entries in the Outline view you will see a fairly complex property tree in the Property view (this is the way I test the PSV). In this case if I expand 'address' for example you can switch between different players without issues but if you select 'Team1' and then select a player you'll see that the tree is collapsed again. For some reason the expansion of the 'address' sub-tree never cause the string to be added to the map.
Hey Eric, Sorry for the waaaay late response to this. > The expanded list is 'static' but there can be many instances of the > Properties View open at the same time. I suspect that this may cause > issues in multi-instance scenarios. Ah, something I hadn't considered since our product only allows one Kernel Objects View. > Using the text string may also be prone to 'false positives' should > two different input sources use the same label (i.e. "Address"), is > there any more unique way to determine if it's the same field ? Are you referring line ~1309 (approximate) in the PropertySheetViewer class that that calls the .contains() method on the expandedPropertyGroups HashSet? In any event, you are correct: It does appear that there could be false positives using this approach. Maybe I should be called .equals() here. Frankly, since I created this patch nine months ago, I don't fully recall why I chose .contains() instead of .equals(). > Finally I tried this out using the 'org.eclipse.ui.examples.readmetool' > and the current code doesn't appear to keep track of an entry's expanded > state unless it's at the 'root' of the tree. You are correct. The patch doesn't remember (or restore) anything beyond one branch from root. Anything beyond this point wasn't needed for our purposes, and, frankly, I naively never considered that expanded/collapsed state beyond the first branch would be needed elsewhere. So, you bring up a good point. But it's not clear to me whether remembering the expanded/collapsed state is something that would be of benefit many or only a limited audience :-). Opinions are welcome! And again, sorry for the delayed response.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
