Create your own customizations

You have the option (or it is already available) to put at that same spot a CustomDataViews.plist containing rules to format data. Edit $HOME/Library/Application Support/Apple/Developer Tools/CustomDataViews/CustomDataViews.plist to meet your needs.

Create your own customizations

A format string consists of literal text, references to child data values of a structured variable (as they appear in the outline view), and/or arbitrary expressions, in any combination. This lets the user build a custom string consisting of interesting fields and properties of a variable. The user edits the format string by double clicking the appropriate column for any variable.
 A child reference looks like:
 
 %childPath%:referencedColumn
 
where childPath is a . delimited "path" to the child data value being referenced (A numeric reference is also supported, so format strings can refer to the n'th child rather than naming the child.) The % characters bracket the child path. The referencedColumn is one of the characters n, v, t, or s, indicating to use text from the variable name, value, type name, or summary entry of the referenced child. The referencedColumn and it's preceding colon can be omitted, in which case the value column is used as the default.
Take for example the NSRect produced by NSMakeRect(1,2,3,4). The format string:
	x=%origin.x%, y=%origin.y%, width=%size.width%, height=%size.height%
 
would product the display:
x=0, y=1, width=2, height=3
Or, another example, if the format strings for NSPoint, NSSize, and NSRect are (respectively):
	x=%x%, y=%y%
	width=%width%, height=%height%
	origin=(%origin%), %size%
 
Then the display of the rect would be:
origin=(0,1), width=2, height=3
Note that the formatted display for the origin is used in the display for the NSRect. The format strings are "recursive".
For C++ code it is not necessary to include the public, private, or protected entries in the child path. These "fake" children are automatically skipped. For example, in a C++ program the structure in the variable view might look like rect->public->origin->public->x. But to reference the child it is sufficient to write %origin.x%.
The expression form in a format string looks like:
	{expression}:referencedColumn
 
This is similar to the child reference, except that braces {} are used to bracket the expression rather than % characters. The referencedColumn is the same as for a child reference (above). Inside an expression, the text $VAR is replaced with an expression for referencing the variable itself. Thus, the equivalent expression for the first NSRect example above would be:
	x={$VAR.origin.x}, y={$VAR.origin.y}, width={$VAR.size.width}, height={$VAR.size.height}
 
This is a relatively simplistic example, as there is no computation associated with these expressions, and in such a case the child referencing form is more efficient. But any expression can theoretically be used, which could include function calls. So for a NSArray you might have a formatter like:
	count={(int)[$VAR count]}
 
This format string would show the count of objects in the array. Note that dynamic expressions must be evaluated every time the process stops, including after each step. So format strings which are computationally expensive can degrade stepping time.
There are some additional special symbols (besides $VAR) that can be used in an expression. The complete list and their meanings is:
  • $VAR - replaced with an expression evaluating to the variable itself
  • $ID - replaced with an identifier which can be passed to a plugin function (see below)
  • $PARENT(type) - replaced with an expression for the parent of the variable which is of the given type. This is only useful for a very limited circumstance, where values of a particular type are always contained in a structure of known type, and information from the containing structure is required to interpret the value. For example, an "event" structure might contain an "eventType" code, and an "eventResult" value, where the eventResult values are overloaded for different eventTypes. This construct provides a mechanism for the eventResult formatter to obtain the containing event to access the eventType.

Custom format strings are stored and looked up on a per type basis. So if you set a format string for a given data variable, all other variables with the same type will get the same format string. Type attributes are stripped from the type name, so "const NSRect", "volatile NSRect", and plain "NSRect" all get the same formatters.

The .plist file which contains format strings is a simple dictionary. The keys are type strings and the values are formatter dictionaries. Additionally, the dictionary has a key named "File Version" whose value is the file format version number (currently 1).

For the version 1 file format each formatter dictionary has two key/value pairs. The keys are "ValueString" and "SummaryString", and the values are the custom formatter strings as described above.

Creating a new .plist file is relatively straightforward. Formatter strings can be entered directly into the GUI by double clicking on the value or summary columns. This will store the required entries into the user's customized plist (~/Library/Application Support/Apple/Developer Tools/CustomDataViews/CustomDataViews.plist). The appropriate entries can be copied to a .plist file with a different name in any of the above locations and it will be loaded the next time Xcode is restarted.

Download a sample custom pList file