Community
Participate
Working Groups
The input to the expression view is fixed to getViewer().setInput(DebugPlugin.getDefault().getExpressionManager()) inside the ExpressionView.setInitialContent() method. Since there can be only one IElementContentProvider for the ExpressionManager, there is no way to provide alternative contents in the expression view as in the Variables and Registers views.
Created attachment 65040 [details] Patch to address the problem. The fix in the patch does not change any APIs but it does complicate the content providers for the standard debug model a bit, so hopefully this bug can still be addressed in 3.3.
Some issues: * Every debug model has to account for the expression view for any one of its debug elements that can be the active context. For example, since the Java thread content provider does not acconut for this, the expression view goes blank when a java thread is selected. * The view refreshes on each input change which does not currently save/restore expansion state (so all elements are continually collapsing). Can you just add custom expressions to the manager to get the same effect? Each expression can have custom content, but the root elements would need to be expressions.
I agree that this is problematic :-( I was hoping that we could use the expressions view to show variables and registers with the same features as they have in their own views: i.e. custom columns and cell editors. Extending IExpression could actually work well... the only sticky point might be the column provider. Currently there is no column factory registered for IExpressionManager, but if we were to register one, it would apply to all debuggers.
Another problem is that if we provided our own IExpression implementation, we would not be able to re-use the IWatchExpression objects that are added by the expression view's standard actions. I tried to think of another way to solve this problem but I keep running into the fact that there can only be one content provider per element... which has to work in all views.
(In reply to comment #3) > I was hoping that we could use the expressions view to show variables and > registers with the same features as they have in their own views: i.e. custom > columns and cell editors. Yes - we've purposely avoided columns in views that show elements from different models at the same time.
It's too late to do anything about this bug in 3.3, so this is just for future consideration. With in mind I think there are three possible resolutions to this problem: 1) Leave the expression view as it is. This means that practially speaking expression view will display only WatchExpression/IVariable/IValue based data. Custom columns and cell editors that are available in Variables and Registers views are not going to be usable in the expression view. If our marketing/customers demand that we have a watch view that has the above features, we will just introduce a separate "Watch" view with customizable content. 2) Apply the patch plus saving/restoring view expansion state. Custom content would work, but other custom content providers would have a further complication on top of an already complicated set of API requirements. 3) Introduce a new API/extension point to allow the expression view input and/or content provider to be selectively overriden. Whatever mechanism is introduced here, it will at least partially overlap with the functionality of flexible hierarchy itself. Which kind of begs the question whether it would be better to try to somehow address this in the flexible hierarchy APIs themselves. ---- Option 1 is obviously least favorable to us, but I can also see some valid arguments for it. Option 2 and 3 are pretty much equivalent in terms of functionality, so it's just a matter of deciding on the correct architecture.
marking assigned for future consideration.
Comment on attachment 65040 [details] Patch to address the problem. I submitted an updated patch for bug 184057, which includes changes needed to address this bug.
The updated patch (which should be separate from bug 184057 and attached here) needs further review. The patch will require the content providers of debuggers to call the super class or provide expression information.
An alternative method to address this bug would be to use a view input "proxy" as has the been suggested in bug 176627. A proxy could supply a default content provider and would eliminate the need to change the default adapters for the standard model.
Created attachment 79663 [details] Patch to fix bug based on 3.4 M2 sources. I created a new fix for this bug based on the new IViewerInputProvider interface. This patch does not require any changes in the content providers for the standard debug model elements. With this patch, a debugger which needs to customize contents of the expressions view will need to provider its own implementation of IViewerInputProvider, which in turn will provide an alternative input object into the view (as opposed to the default: ExpressionManager instance).
Consdier for 3.4
Created attachment 82873 [details] Updated patch Patch adds IViewerInputProvider adapters for IDebugElement, IProcess, ILaunch so the viewew does not go "empty" when a non-stack frame element is selected. The default "viewer input provider" was provided, but the other elements were not adapted to it.
Applied patch with modification to contributed adapters for standard debug elements.
Please verify, Curtis.
Thank You! But I also discovered another flaw with this patch recently: when the view is hidden, VariablesView.becomesHidden() calls setViewerInput(null). Since ExpressionView.setViewerInput() overrides setViewerInput() to re-set input to ExpressionManager, the view ends up evaluating expressions when the view is not visible. In our product patch we didn't use the DefaultInputProvider, so overriding setViewerInput() was necessary to populate the view for non-DSF debug models, but I think in this patch, it's not necessary to do to override setViewerInput(). BTW, what we did to work around this problem is to add protected void becomesHidden() { super.setViewerInput(null); } to ExpressionView, but this makes an assumption about what is in super.becomesHidden() so it's not ideal.
Re-open to address updating while hidden.
Also, I think with this patch, it's not necessary to override becomesVisible() anymore either, because contextActivated() will override it anyway.
Fix is to set the input to the expression manager when the active context is null or empty. No longer need to override becomesVisible() or setViewerInput(), and can get rid of setInitialContent().
Many thanks :-)
Verified.
