views:

66

answers:

1

I just recently began using synthesized instance variables in my iPhone projects. The problem is, I can't see the synthesized ivars in the debugger. Is there any way to view the properties of an object in the debugger when it's not using the explicitly declared instance variables?


I need to clarify the second question. I'm not asking about how to access properties, or what they do; I know all that stuff. I was under the impression that you could not access instance variables directly when using synthesized ivars based on this post. I've clearly been able to do what I previously thought wasn't possible. I'm wondering what's going on.

I'm using Xcode 3.2.4/iPhone Simulator/LLVM Compiler 1.5.

+2  A: 

Edited to add answer to second part:

This works on Xcode 3.1 so I don't see why it won't work on later versions

What you could do is send messages directly to the object from the console while debugging.

Presumably you've stopped at a breakpoint and you're looking at the variables in the debug view. for objects, these show you the pointers. You may not see the iVar, but you have the pointer to the object and you can send it messages. for example:

  • You've stopped at some breakpoint within the object
  • The variable view shows the pointer address of self to be (say) 0x1031380.
  • In the console type po [0x1031380 title] (note that there is no semicolon) and enter
  • You should see the what you want in the console.

When you declare a property with (retain) and subsequently synthesize the property, you're creating setters that retain the object/value passed to them. so in your case above you should rewrite the method as:

- (void)viewDidLoad {
    self.title = @"woah";
}

And the string will be retained as part of the setter. Also, I prefer to use (copy) for class clusters that have mutable/immutable pairs (NSString, NSSet, NSArray, etc). That way, the property can't be changed externally.

Abizern
Actually, it's not so much a case of preference as you *should* use copy properties for NSString etc unless you have a very good reason not to.
JeremyP
I got rid of the dummy code, since it seemed to be causing some confusion, and I clarified the second part of my question.
kubi
`po [0x1031380 title]` That's the answer, thanks! Having to use text commands to see iVars + no protection from directly accessing iVars means that I'm probably not going to continue using synthesized iVars. It's a pain and it doesn't seem to actually get me anything useful.
kubi