Memory view preferences
You can set table rendering, codepage, and padded string preferences for memory renderings. In addition, you can modify the preferred behavior for resetting memory renderings.
Memory view preference dialog boxes are opened from the Memory view down-arrow icon menu. To open the Memory view Preferences dialog box, click the Memory view down-arrow icon and select Preferences from the menu. To open the Memory view table renderings Preferences dialog box, click the Memory view down-arrow icon and select Table Renderings Preferences from the menu.
To restore any changes that you make in the preferences to their default settings, click Restore Defaults.
Preferences: Reset Memory Monitor
You can reset a rendering to the base address if you have moved away from it. When you reset a rendering to the base address, you can set it to reset only the visible renderings - or you can set it to reset all renderings. If you choose to reset all renderings, performance of the reset operation can be negatively impacted. To set this preference, open the Preferences dialog box and then select the Reset Memory Monitor node. In the Reset Memory Monitor page, choose the appropriate radio button.
Preferences: Padded String
The padded string is the string that will appear in memory contents when memory cannot be retrieved. To set the padded string, open the Preferences dialog box and select the Padded String node. In the Padded String page, specify the string that you want to display when memory contents cannot be determined.
Preferences: Select Codepages
When monitoring ASCII and EBCDIC text-based renderings (and mapped memory, if it is available in the product that you installed this debugger with) in the Renderings pane, you can set the codepage in which you want the rendering to be displayed.
To set the codepage for rendering memory to ASCII/EBCDIC, open the Preferences dialog box and select the Select Codepages node. In the Select Codepages page, specify the codepage of the character set that you want to change (for ASCII renderings, EBCDIC renderings, or both).
Table Renderings Preferences
To set preferences for memory renderings that are displayed in a table, click the Memory view down-arrow icon and select Table Renderings Preferences. In the resulting preferences dialog box, there are two options:
-
Automatic radio button: Select this if you want the debugger to automatically preload a buffer of memory before and after the visible region in the Memory view. When you select this setting, you can easily scroll away from the visible region of memory with scroll and page up/down actions.
If the buffer size is large, the performance of refreshing the Memory view can be negatively impacted (the Memory view refreshes when there is a potential for memory change - so, for example, the Memory view refreshes when you step, suspend after running, change a variable or register, or modify memory). This is because a request for more memory must be made from the debug engine for each refresh. On the other hand, if the buffer size is too small, the performance of scrolling can be negatively impacted. This is because a request for more memory must be made from the debug engine when the buffer is exhausted. Given this performance trade-off, you need to set this option to suit your needs.
-
Manual radio button: If you select this setting, then the number of lines per page that you specify will be loaded into the Renderings pane. When using this setting, you have more control in choosing exactly what you want to monitor, however, you will not be able to scroll outside the buffer defined by this page size setting. Instead, to view memory from the next page or previous page, you must right-click to use the Previous Page and Next Page actions from the pop-up menu.
If the buffer size is large, the performance of refreshing the Memory view can be negatively impacted (the Memory view refreshes when there is a potential for memory change - so, for example, the Memory view refreshes when you step, suspend after running, change a variable or register, or modify memory). This is because a request for more memory must be made from the debug engine for each refresh.
