Community
Participate
Working Groups
Build Identifier: 3.7 I20110613-1736 In registers/variables/expression view, value cell is blank when the service's getFormattedExpressionValue() returns with a failed request status. This happens in eclipse 3.7 but not 3.6. In 3.6, the value cell shows the error message in red foregrond like Error: xxx When FormattedValueRetriever calls IFormattedValues.getFormattedExpressionValue() fails, FormattedValueRetriever only puts the returned status into the given IPropertiesUpdate object. It needs to put the status to the IPropertiesUpdate object's property-status map with property IDebugVMConstants.PROP_FORMATTED_VALUE_ACTIVE_FORMAT_VALUE. This is required because AbstractCachingVMProvider's updateNode() uses PropertiesUpdateStatus's mergePropertiesStatus() to merge status, and the latter method checks the status for a given property. If there is no status for the property, the merge method will ignore it although the properties status object itself has status message and has severity != ok. This makes AbstractCachingVMProvider finally lose the non-ok status. This then make org.eclipse.cdt.dsf.debug.ui.viewmodel.ErrorLabelText and ErrorLabelForeground fails to become active. Reproducible: Always
I believe this is the same bug as not reporting errors in expressions view. Please correct me if I'm wrong. *** This bug has been marked as a duplicate of bug 351898 ***
Pawel, This is not same as bug 351898. The fix of 35198 does not help to fix Bug 352788. The reason is patch of 351898 assumes failure comes from service.getExpressionData. The root cause of this bug 352788 is FormattedValueRetriever does not propagate the status proeprly when getFormattedExpressionValue fails. This affects all views using FormattedValueRetriever. In my case, my register name is valid, nothing deal with VariableNode and getExpressionData. In my another case, I have a valid expression that does not fail getExpressionData and only fails getFormattedExpressionValue().
(In reply to comment #2) Hi Winnie, did you also consider the changes in bug 351898 comment#2. Unfortunately I hadn't produced a patch prior to committing that one.
(In reply to comment #3) > (In reply to comment #2) > Hi Winnie, did you also consider the changes in bug 351898 comment#2. > Unfortunately I hadn't produced a patch prior to committing that one. I did not see there is a change to PropertiesUpdateStatus. Just quickly try the code and I see this bug is addressed. In my case, I don't need the change in VariableVMNode. Please mark this bug properly. Thanks.
Marking back as duplicate after clarification. *** This bug has been marked as a duplicate of bug 351898 ***
