Community
Participate
Working Groups
The feature for retrieving limited number of stack frames is somewhat challenged when using the new Debug view breadcrumb: 1) The double-clicking no longer works. This is expected since in the drop-down a single click closes the drop-down. I also don't think there's anything we can do about this, it's going to have to be a limitation of the breadcrumb. 2) If I select the <more frames> frame, I can bring up the context menu and select "Expand Stack". This works, but following this action the retrieving of limited frames stops working all together, the full stack is always retrieved. 3) After selecting the expand stack action as above, the breadcrumb shows "No Active Context" because the selection is lost in Debug view. After retrieving new stack frames, selectihon should be reset to the first newly retrieved stack frame.
I tracked this down to bug 266308. By disposing the presentation context, the properties are all cleared where the current stack frame limit is stored. The same bug resets also the update mode settings.
(In reply to comment #1) > I tracked this down to bug 266308. This refers to 2). 3) is still open, but it is actually independent of the breadcrumb.
(In reply to comment #0) > 1) The double-clicking no longer works. This is expected since in the > drop-down a single click closes the drop-down. I also don't think there's > anything we can do about this, it's going to have to be a limitation of the > breadcrumb. What if we changed the more stack frames behavior to expand simply in response to activation? It might be a little startling but would definitely be more friendly in the breadcrumb.
Created attachment 140757 [details] Select stack frame after expansion This is a fix for issue 3). (In reply to comment #3) > (In reply to comment #0) > > 1) The double-clicking no longer works. This is expected since in the > > drop-down a single click closes the drop-down. I also don't think there's > > anything we can do about this, it's going to have to be a limitation of the > > breadcrumb. > > What if we changed the more stack frames behavior to expand simply in response > to activation? It might be a little startling but would definitely be more > friendly in the breadcrumb. > I tried to change the expand stack behavior to be triggered by viewer open events instead of double clicks. That way we could keep the current behavior for the normal debug view and make it work for the breadcrumb at the same time. The problem is that the viewer which the model proxy gets installed in is no StructuredViewer in case of the breadcrumb (it's a DelegatingTreeModelViewer), therefore we cannot register an open or double click event listener.
(In reply to comment #4) > I tried to change the expand stack behavior to be triggered by viewer open > events instead of double clicks. That way we could keep the current behavior > for the normal debug view and make it work for the breadcrumb at the same time. > The problem is that the viewer which the model proxy gets installed in is no > StructuredViewer in case of the breadcrumb (it's a DelegatingTreeModelViewer), > therefore we cannot register an open or double click event listener. In this case I would like to add methods to add an open listener to ITreeModelViewer interface, but darin doesn't want to make this interface public. I could try to convince him to make it a public interface but we'd need more use cases and it wouldn't show up until 3.6 anyway.
(In reply to comment #4) > Created an attachment (id=140757) [details] > Select stack frame after expansion > > This is a fix for issue 3). I committed the fix to HEAD and cdt_6_0. (In reply to comment #5) > In this case I would like to add methods to add an open listener to > ITreeModelViewer interface, but darin doesn't want to make this interface > public. I could try to convince him to make it a public interface but we'd > need more use cases and it wouldn't show up until 3.6 anyway. Another possibility is to trigger the expand stack on a selection event if the underlying viewer is no StructuredViewer. Unfortunately, DelegatingTreeModelViewer does not forward the add/remove listener methods to the underlying viewer, so this would still require a fix in the platform, but it would not touch API.
(In reply to comment #6) > Another possibility is to trigger the expand stack on a selection event if the > underlying viewer is no StructuredViewer. Unfortunately, > DelegatingTreeModelViewer does not forward the add/remove listener methods to > the underlying viewer, so this would still require a fix in the platform, but > it would not touch API. Yes, I think I could event target that kind of fix for 3.5.1. If you think this is the way to go, please file a bug for platform, and I'll pick it up.
