Bugzilla – Full Text Bug Listing
| Summary: | Request a specific format when opening a memory monitor on variables | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Ken Ryall <ken.ryall> | ||||
| Component: | cdt-debug-dsf | Assignee: | Project Inbox <cdt-debug-dsf-inbox> | ||||
| Status: | RESOLVED INVALID | QA Contact: | Pawel Piech <pawel.1.piech> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | pawel.1.piech | ||||
| Version: | 7.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Never mind, this was a dumb idea. We may still need a better way of getting the "view memory" address of a variable, but our immediate problem is resolved with the fix for bug 309193. |
Created attachment 169885 [details] specifically request expression value for view memory Currently when you attempt to view memory on a variable DsfMemoryBlockRetrieval.resolveMemoryAddress asks for an expression's value as IFormattedValues.HEX_FORMAT and then turns this into an address value to use for the memory monitor. This works OK in simple cases but sometimes when viewing memory on some types people expect to inspect an address that isn't the one you would put into the Variables or Expressions view. Also if the Expressions service is employing a custom formatter to on the expression it may return a value that can't be readily turned into an address. This patch contains a low impact solution for this, which is to add a new format IFormattedValues.ADDRESS_FORMAT that lets the Expression service know the request is specifically for viewing memory on that expression. Alternately a new API could be added to IExpressions2 to replace the use of getFormattedValueContext. The attached patch also fixes a problem where no error is reported when viewing memory on a variable fails.