• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Displaying string variables in debugger...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Displaying string variables in debugger...


  • Subject: Re: Displaying string variables in debugger...
  • From: Jim Ingham <email@hidden>
  • Date: Thu, 19 Aug 2004 13:58:56 -0700

Kevin,

I was assuming you had ALREADY set up the formatter for the char[128] type. Then it will work.

The struct formatter was just picking up whatever would be in the summary column of it's sub-elements. For there to be something there, you have to have a formatter for the type of the sub-element.

wchar_t is just a store for Unicode characters, right? I can't see a way off the bat to write a data formatter that would tell Xcode that it needs to print the data it gets back as Unicode. If you had a routine that converted the wchar_t data into a C-string with unicode escape sequences, that might work. I don't know of a cast that will achieve that, but you could probably write a simple C routine to do that & call it in your formatter. I don't actually know if this will work, but it is the only thing I can think of off the top of my head.

And please file a bug on getting a way to specify a formatter for char arrays that is independent on array size. That would be a useful addition.

Jim

On Aug 19, 2004, at 12:48 PM, Kevin Hoyt wrote:

Jim,
Thanks for more information....

I tried your suggestion for seeing the array of characters inside a
struct. It would not work for me. Seems like your suggestion should
include the formatter required to display the array of characters that is
needed for the same arrays outside of the structure? I played around with
that, but I have no idea what to do...


Any comment on the wchar_t formatter?

So should I file a bug or a feature request so it's easier to apply a
string formatter to variables, including a more generic one that is not
dependent upon the array size?


Jim Ingham <email@hidden> wrote on 08/19/2004 10:43:15 AM:


On Aug 19, 2004, at 8:46 AM, Kevin Hoyt wrote:

Great! That does let me see the strings...
And, just for posterity, this format string needs to be added with the
'edit summary format' menu item or by double clicking on the Summary
column.
Thank you for the help :-)



However, now I have even more questions...
Why do I have to do this in the first place? Character strings really
seem like a basic data type that Xcode should be able to display be
default. Is Xcode's behavior by design, is there something funky with

my
installation, or is this a bug?

These aren't character strings, they are arrays of characters. There is no guarantee that they are null terminated, and many folks use them a arrays of characters - or even arrays of 1 byte objects, not as strings... So the default behavior is to display them as arrays and not to try to print them.

Still, it is also quite common to use them to store strings.  And so
Xcode should make it easier to format the summary column as a string,
though again, you need to be able to turn it off...


A search of Xcode help comes up with one page that describes 'summary
format.' What does it mean when it says "you can not specify a custom
format for string types, such as NSString, char*, and so on." Isn't
that
what I just HAD to do because they are not displayed by default???

NSString & char * are handled internally in a different way from most
other types. The fact that you can't override the formatters for these
few types is more an accident of implementation (and arguably a bug)
than any design. And as you found out, character arrays are not among
the set that is handled this way.



Anyway... The formatter only worked for the one variable I set it for. I have several others of the same type that are not using the custom formatter. Based on what I found in DataFormatterPlugin.h, I thought it would be applied to all variables of the same type.

More searching shows where the problem may be...
Let's say that I have three local buffers declared as:
char buf1[128];
char buf2[256];
char buf3[256];

And I create a formatter for the first one as {(char *)$VAR}:s
buf1 will now show as a string in the Summary column.
buf2 does NOT :-(

Taking a peak at ~/Library/Application Support/Apple/Developer
Tools/CustomDataViews/CustomDataViews.plist shows the following
formatter
has been created:
Dictionary: char[128]
   SummaryString: {(char *)$VAR}:s

So this means the formatter is ONLY applied to char strings in 128
buffers... the 256 ones do not match!

Yes, the match is against the type, and the type that is recorded in
the debug info for this variable is char[128] not just char[]. In this
case, it would be a good enhancement for Xcode's type match operation
to consider all array sizes to match the same formatter, but that
facility doesn't exist right now.



Sure enough, if I add a second formatter for char[256], buf2 and buf3 show the Summary.

Is it possible to make a formatter that will apply to all character
buffers regardless of their size?


No, see above.


Also, what about more examples? For instance, what would a formatter look like for wchar_t strings? Or showing multiple strings from inside a structure like this: typedef struct myBuffs { char buf1[128]; char buf2[256]; char buf3[512]; } myBuffs_t;


There is some (admittedly very brief) description of how these work in the Xcode help:

file:///Developer/Applications/Xcode.app/Contents/Resources/
English.lproj/Xcode_Help/Debugging/chapter_9_section_9.html#//
apple_ref/doc/uid/TP30000835/BCIFFJAB

We also talked about this in some detail at WWDC.  Dunno how/if ADC is
going to release the sessions, but if you can get your hands on the
Debugging session, there is more there.

This one would follow somewhat the example given for NSRect in the
help, if you put:

buf1: "%buf1%:s" buf2: "%buf2%:s" buf3: "%buf3%:s"

jn the formatter for struct myBuffs, then you would see in the summary
for a variable of type myBuffs:

buff1: "some string" buf2: "some other string" buf3: "yet another
string"

if you filled the buffers with "some string", "some other string" and
"yet another string" respectively. The difference between this and the
NSRect example is that we had to put the :s after the sub-element
entries because we wanted to display the Summary column entry for the
sub-element, not the Value column entry, in the structure summary
element.


Note that we treat typedef's & raw types separately. So if you entered
this for a variable you had defined as "struct myBuffs", it would not
be used for one you had defined as myBuffs_t. This is correct
behavior, since you do want to be able to distinguish between typedef
of say an int (like OSType) and the bare int type.


Jim




email@hidden wrote on 08/19/2004 01:07:59 AM:

How about this data formatter:

   {(char *)$VAR}:s

-chris

On Aug 17, 2004, at 11:03 AM, Kevin Hoyt wrote:


For example if I have char myString[]="myString";

I can not get myString to show in the debugger.

Any suggestions?
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.


  • Prev by Date: Re: Displaying string variables in debugger...
  • Next by Date: Re: XCode 1.5 Java Indexer bugs
  • Previous by thread: Re: Displaying string variables in debugger...
  • Next by thread: Linking against libraries
  • Index(es):
    • Date
    • Thread