Bugzilla – Full Text Bug Listing
| Summary: | [PropertiesView] PropertySheet displays wrong values with multiple selection | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Randy Hudson <hudsonr> | ||||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | krzysztof.daniel, n.a.edgar, snorthov, Tod_Creasey | ||||||
| Version: | 2.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 2000 | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
|
Description
Randy Hudson
Should either show the values of the focus item, or show no value if they are inconsistent aross the selected items. Checkbox presentation of boolean properties can be handled specially: - cleared if all are false - checked and white if all are true - checked and gray if some but not all are true (selecting this turns them all to true) As far as displaying that the values aren't consistent, there is nothing that can be done. The CellEditor is never given multiple inputs, and it isn't displayed anyway unless you edit the value (unless this has changed in a recent build). All you get is a String to be displayed in the TableTree. You could play some tricks with the String, but showing no value is not acceptable. The ordering of the items in the selection is the policy of the widget/viewer. The tree view orders them depending on the position in the tree not the selection order. Thus changing the way the property sheet picks the "first" item will not help in this case. We do need a better way to indicate values in the multiple selection case. Can we change it to be the last item anyway? Under the assumption that most of the time people multi-select from top-to-bottom, which results in the "focus" for native widgets being the last Item, not the first. In GEF, we maintain the selection order, and focus stays on the item most recently selected, just like in the Tree. But more importantly, our focus matches the last element in the ISelection. Created attachment 25082 [details]
Changed to use the LAST entry in the values array rather than the first
Note that this may change during review of the overall handling of the multiple
select cases (one thought is to not show a value unless all 'suppliers' match)
but this is at least closer that what we had.
It's worse than that. Tree.getSelection() states: "The order of the items is unspecified." and due to the way it maintains its list of items, the order can be essentially random. E.g. if you create A, B, C, delete B, then add D at the end, and select all 3, getSelection() will return A, D, C. In JFace, we could sort the selection based on the viewer's sorter, but we probably would not want to do this all the time for performance reasons, and that still wouldn't help for determining the focus item. It would also help to have API to get the focus item. Without this, we may be able to leverage the item passed in SWT's selection event. In the case where an item is being added to the selection (and hence will become the focus item), I believe that's the item the event carries. Not sure what happens in the ctrl+click to deselect case. Given the above, I don't think there's much point in just changing it to use the last item in the selection rather than the first. Trees are not the only thing providing selection to the propertysheet. The behavior may be undefined for Tree but it is not for GEF. It turns out tree was a bad example and I should have used GEF's graphical editpart viewer instead. The patched behavior is not worse than before, and it helps us out. Separate bugs should be opened for the problem with indicating dissimilar values. The problem with changing this is that if anyone is relying on the current behaviour we will break them. It may be inconsistent but I woulkd be nervous about introducing a significant behavioural change for this. (In reply to comment #9) > The problem with changing this is that if anyone is relying on the current > behaviour we will break them. It may be inconsistent but I woulkd be nervous > about introducing a significant behavioural change for this. In comment 6 Nick says the return order is random, so no one could be depending on any order assuming that native widgets are the selection source, as in Jface. Created attachment 57701 [details]
Blanking not equal property values
Patch allows for optional blanking not equal property values.
Daniel, I'm assuming that all existing code will run using this patch without any changes (i.e. using the old behaviour). Do you have a test project that I can use to test this patch?? The second patch is not related to this bug. Please open a separate bug report. *** Bug 173004 has been marked as a duplicate of this bug. *** 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 and remove the stalebug whiteboard tag. 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. |