Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 343021

Summary: variable/expression/register cell modifier need to try to get element format when in editing values
Product: [Tools] CDT Reporter: Winnie Lai <wlai>
Component: cdt-debug-dsfAssignee: Patrick Chuong <pchuong>
Status: RESOLVED FIXED QA Contact: Pawel Piech <pawel.1.piech>
Severity: normal    
Priority: P3 CC: cdtdoug, pchuong
Version: 8.0   
Target Milestone: 8.0   
Hardware: PC   
OS: All   
Whiteboard:
Attachments:
Description Flags
bug fix
none
patch
none
patch
none
bug fix pchuong: iplog+, wlai: review?

Description Winnie Lai CLA 2011-04-15 16:56:58 EDT 
Build Identifier: 3.7 M6 I20110310-1119

If variables/expressions/registers view supports individual element format and a value is being displayed with its element format rather than view's preferred format, then the cell modifier for that value should try to get element format to fill edit box, instead of using the preferred format.


Reproducible: Always

Steps to Reproduce:
1. Make a row element to use a number format that is different than preferred format of the view.
2. Edit the value column of the element.
3. The edit text box comes up but is filled with a value using preferred format. We expect the text box shows a value using the element format -- the same format that is being used to display the value in the view when it is not in editing mode.
Comment 1 Winnie Lai CLA 2011-04-15 17:26:23 EDT 
Created attachment 193408 [details]
bug fix

The fix modifies VariableCellModifier, RegisterCellModifier, RegisterBitFieldModifier, and WatchExpressionCellModifier in org.eclipse.cdt.dsf.ui.

The fix relies a change in InternalTreeModifier.CellModifierProxy (in org.eclipse.debug.ui) to communicate more detailed information about the element being modified. See its markCellBeingModified method for details.
Comment 2 Pawel Piech CLA 2011-04-15 18:35:28 EDT 
(In reply to comment #1)
> The fix relies a change in InternalTreeModifier.CellModifierProxy (in
> org.eclipse.debug.ui) to communicate more detailed information about the
> element being modified. See its markCellBeingModified method for details.
I don't think using the presentation context for this purpose is going to be acceptable.  You could file a separate bug with platform debug to extend the cell modifier API to use full tree paths, but we'd need support from jface to make that happen, which is not likely.

I hate to say it, but you're more likely to have success adjusting the individual cell format logic to handle the element and not use a full path.
Comment 3 Winnie Lai CLA 2011-04-16 22:38:58 EDT 
Created attachment 193428 [details]
patch

Please review the patch for 3.7 M7.
Comment 4 Winnie Lai CLA 2011-04-25 11:01:07 EDT 
Created attachment 193991 [details]
patch

In response to Pawel's comment (comment #2), this patch does not require InternalTreeModelViewer to provide a fully qualifed tree path.

Please review this patch. I would like it to be included in 3.6 M7.
Comment 5 Patrick Chuong CLA 2011-04-28 13:51:41 EDT 
I looked at this patch, it looks fine to me. However, I would like to see the duplicated code refactored to the base WatchExpressionCellModifier class.
Comment 6 Winnie Lai CLA 2011-04-28 14:31:11 EDT 
Created attachment 194298 [details]
bug fix

This patch puts the common code into the WatchExpresionCellModifier.
Comment 7 Patrick Chuong CLA 2011-04-28 15:32:00 EDT 
Thanks Winnie. Committed to HEAD.