Ok,

Few quick answers, yes it's being synthesized and no, I haven't specified my own setters/getters, i'm just letting Cocoa do that part itself.

When I step through the process in debugger it just confuses me more.
I've put a breakpoint on the "self.delegate = tDelegate" assignment and stepped through each part of the process (until the error occurs).

Note: the getters/setters discussed here have been created by the synthesize process

This is what I get:
1.      self.delegate = tDelegate                       // tDelegate is set to 
the delegate
2. [self setDelegate:tDelegate] // self.delegate is set to tDelegate (which is correct) 3. NSLog(@"%@", self.delegate) // self.delegate is set to NSAutoreleasePool 4. [self delegate] // self.delegate is set to the delegate, but returns an NSAutoreleasePool

So it seems the getter generated by the synthesize process is doing something strange, cause if I check in the debugger self.delegate is set to the right variable, the method simply returns something strange. I've also tried specifying my own getter & setter, but I get the same results - it's only when I just assign the variable directly that I have access to the delegate at all times.

On 07/03/2009, at 10:18 PM, Roland King wrote:


On Mar 7, 2009, at 2:18 PM, Aaron Wallis wrote:

The property was assigned as:
@property (retain) id delegate;

when I walk through the code (and log pretty much everything out)
I get the following:

- (void)processString:(NSString *)tString withDelegate: (id)tDelegate { NSLog(@"1. %@", tDelegate); // I get <TMPSTProcessDropOperation: 0x175930>

self.delegate = tDelegate;

NSLog(@"2. %@", self.delegate); // I get <NSAutoreleasePool: 0x187e10>

[self.delegate doSomething]; // I get -[NSAutoreleasePool doSomething]: unrecognized selector sent to instance 0x187e10
}



and you are @synthesize-ing this property? There are no warnings in your code about redeclaring variables or not synthesizing methods? You're not inheriting from something else which declares a delegate? Have you written a -(void)setDelegate:(id)delegate method, because if you have that's what self.delegate is calling, that line of code is identical to [ self setDelegate:tDelegate ]. If you have for some reason written that method, even if you synthesize the property, synthesize will not overwrite it.

What's bizarre here is that what is ending up in self.delegate is an object with an entirely different address. I could believe that you have an overreleased object and the memory was being reused and it *looked* like an autorelease pool, but it's just not the same pointer at all. You are telling it above, set self.delegate to the object at 0x175930 and yet what ends up in delegate is the object at 0x187e10.

That's why I ask if you have a -(void)setDelegate: method which is broken and not actually setting the delegate to the argument you passed in.

What happens if you single step INTO that self.delegate = tDelegate method? If it's synthesize I think the debugger just moves to the @synthesize line for one or two steps, you don't actually see any code, if you have another setDelegate: method you're calling, it should go there and you'll see what's going on. Also, what is self.delegate set to before set it to tDelegate?

Note that all the other comments about setting a delegate once and not retaining it are very valid and true. Its not a hard and fast rule the delegates are unretained, but in many cases if delegate means what it usually means, you end up with a retain cycle if you retain them.

Your solution, setting the delegate member variable directly, sort of breaks your own encapsulation. That's exactly what self.delegate = tDelegate should do. Focus on that line of code and figure out what it doesn't do it.



_______________________________________________

Cocoa-dev mailing list ([email protected])

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to