Community
Participate
Working Groups
N20100202-2000 The Breakpoints view doesn't always link with the Debug view any more. I have "Link with Debug View" enabled, and "Group By > Breakpoint Working Sets". When the Breakpoints view is freshly created, all working sets are now collapsed (in 3.5.2, they used to be expanded). When the Debug view now hits a breakpoint, the breakpoint does not get revealed and selected. After I manually expanded the right working set, the linking starts to work. I guess there's a problem in the content provider's getParent(..) method, which prevents the BP from being found as long as the viewer model is not populated.
(In reply to comment #0) > When the Breakpoints view is freshly created, all working sets are now > collapsed (in 3.5.2, they used to be expanded). This issue is tracked in bug 297762.
Created attachment 159506 [details] Patch with fix. This patch converts the track selection handling to using model deltas instead of the view attempting to set selection. Setting selection didn't work for un-expanded elements in the view, because the view is now lazy loading. The only limitation of this fix is that if a thread has multiple breakpoints associated with it, only one of the breakpoints will be selected. I'm not sure how important a use case this is. If we need to overcome this limitation, we'll need to add a new capability to the flexible hierarchy viewer to specify a multi-selection through the delta mechanism. Finally, this patch makes a small change in the provisional API of the breakpoints view (added a new constant in IBreakpointUIConstants, and changed the value type of another). This will affect CDT which already uses the new view. Also, it removes an internal interface IBreakpointOrganizerInputProvider as part of refactoring (bug 303261). I'll hold off on commiting till I hear from patrick on bug 303261.
> Setting selection didn't work for > un-expanded elements in the view, because the view is now lazy loading. Selecting un-expanded elements also works in lazy trees, but you need to implement ILazyTreePathContentProvider#getParents(Object).
I committed the fix. Darin please review.
(In reply to comment #3) > Selecting un-expanded elements also works in lazy trees, but you need to > implement ILazyTreePathContentProvider#getParents(Object). Thank you. The flexible hierarchy viewer abstracts this interface from the model so it's not an option in this case.
If there are multiple breakpoints in one method (for example line breakpoints), the selection in the BP view does not change as one resumes from one breakpoint to the next. I suspect this is because the debug context has not changed? (i.e. still the same frame...) but I have not tracked it down.
(In reply to comment #6) > If there are multiple breakpoints in one method (for example line breakpoints), > the selection in the BP view does not change as one resumes from one breakpoint > to the next. I suspect this is because the debug context has not changed? (i.e. > still the same frame...) but I have not tracked it down. I see now: PresentationContext.setProperty() filters out the change in activeContext because it's the same as the previous context... so the update gets lost. I guess I'll have to find a different way to track the active context.
(In reply to comment #7) > I guess I'll have to find a different way to track the active context. What if we added the following to IPresentationContext: /** * Returns the part that this presentation context is associated with. * May return <code>null</code> if the presentation is not associated * with a part. * * @return IWorkbenchPart or <code>null</code> */ public IWorkbenchPart getPart(); /** * Returns the window that this presentation context is associated with. * May return <code>null</code> if the presentation is not associated * with a window. * * @return IWorkbenchWindow or <code>null</code> */ public IWorkbenchWindow getWindow(); I've come across other cases in DSF where I needed access to the view from the content provider or the model proxy. So this would be a welcome addition. There may not be an associated part or window, in which case the model will have to present data without it.
Do we need to use the presentation context for this? would it be simpler just to implement it in the view?
(In reply to comment #9) > Do we need to use the presentation context for this? would it be simpler just > to implement it in the view? The view used to do the selection and that resulted in this bug. It would try to select a breakpoint which was not yet realized in the viewer. This fix moves the responsibility of selecting the breakpoint to the model proxy. The model proxy needs to know the active debug context to figure out what to select and when to update the selection. Unfortunately we don't have an easy way for the model proxy to figure out the debug context since the viewer input is overriden.
Created attachment 160139 [details] Fix attempt #2. This fix adds the IPresentationContext.getPart() as described above and it makes the BP manager content provider listen to debug context changes directly. In the process of implementing this I also tried to reduce the number of locks being held while processing model changes. One annoying side effect I discovered is that if selection is changed in DV very fast, it queues up a number of selection deltas be processed in the Breakpoints view. This is actually visible on my machine Linux32/gtk in that the breakpoints view toolbar flickers. We could address this in a few different ways, e.g. delay the selection in Breakpoints view very briefly and drop the delta if a new selection request comes in. Darin let me know if you'd rather not add the presentation context methods. There actually already is a PartPresentationContext, but if its use is to be so wide-spread I think it makes sense to put it in the interface.
I'm OK with this change.
I committed the changes with additional fixes, refactoring, and comments. Patrick please have a look at this as well since you've authored much of the logic.
(In reply to comment #12) > I'm OK with this change.
