Bugzilla – Full Text Bug Listing
| Summary: | Selection and detail string in Variables view lost if label changed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> | ||||
| Component: | Debug | Assignee: | Samantha Chan <chanskw> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P2 | CC: | chanskw, cocoakevin, darin.eclipse, eclipse, jcompagner, n.a.edgar, philippe_mulet | ||||
| Version: | 3.2 | ||||||
| Target Milestone: | 3.2 RC1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
now with the new variables view it is a bit better because you can configure it so that the value is always displayed in a column But it would be nice that the selection (and the tree state) is remembered as good as it can be and that the detail area is filled with the toString() *** Bug 134070 has been marked as a duplicate of this bug. *** *** Bug 128688 has been marked as a duplicate of this bug. *** Created attachment 37438 [details]
work in progress
This patch encodes/decodes expansion/selection using indicies to indicate which elements were expanded/selected.
Fixed selection/expansion state. Changes to AbstractViewerState, MemoryBlocksTreeViewPane, VariablesView and ViewerState. The selection/expansion is now persisted as a path of indicies based on the index of selected/expanded elements in the tree. This avoids having to compare element labels. There is a side effect: when moving from one frame to the next, if a frame has no "selection/expansion state", the state from the previous viewer input is applied. This will expand/select items based on index instead of name, which may have an unexpected result. When the frames are similar (same receiver), this works well - but when the frames are unrelated, it does not work as well (for example, the first item is expanded and its 3rd child selected). Since the content of the view is now generic, we cannot infer any meaning from the labels and determine if the two inputs are related. Will file this issue to be considered in next relase (may require model to provide more API to persist/restore expansion in a model specific way). Still need to address detail pane update. The detail pane required a post selection change event to be fired. Fix is to fire a post selection after an "attemp selection" is successful. Changes to AsynchronousViewer. Fixed. Please verify, Samantha. Please verify, Samantha. *** Bug 120687 has been marked as a duplicate of this bug. *** *** Bug 120628 has been marked as a duplicate of this bug. *** *** Bug 135696 has been marked as a duplicate of this bug. *** Darin - Trying to verify this one. With the introduction of post-selection event, I am wondering if VariablesViewer still needs to call VariablesView#populateDetailsPane in #updateComplete. When the view is updated, and if there is a selection, the listener would always get the post selection event which will cause the details pane to be populated. I am seeing #populateDetailsPaneFromSelection being called twice every time I hit the breakpoint. Once from #updateComplete and once from the listener. Updating after a step would only call that method once. Am I missing a case here? Thanks... Sam Verified that although the method is called mutilple times, the model presentation is only called once. This is ok for 3.2. Need to address this bug before we can improve on not calling #populateDetailsPaneFromSelection multiple times. We need to know when update is finished. https://bugs.eclipse.org/bugs/show_bug.cgi?id=126040 |
I20051130-1215 public class Try { public static void main(String[] args) { String[] chars= {"a", "b", "c", "d"}; for (int i= 0; i < chars.length; i++) { String ch= chars[i]; System.out.println(ch); // breakpoint here } } } - set the breakpoint where indicated - start debugging - select 'ch= "a"' in the Variables view - resume => On the second hit of the breakpoint, the variable 'ch' is not selected any more. This is a regression compared to 3.1.1. If you select 'chars= String[4] (id=12)', then it works slightly better: The variable is still selected in the Variables view, but the detail pane stays empty. I would expect to see the new value automatically, without having to select the variable again. This also worked fine in 3.1.1.