Re: Attack of the Nils!
Re: Attack of the Nils!
- Subject: Re: Attack of the Nils!
- From: Kevin Callahan <email@hidden>
- Date: Mon, 30 Dec 2002 15:12:16 -0800
It would also be interesting to see the code where the controller is
created.
Kevin
On Monday, December 30, 2002, at 03:02 PM, Michael Latta wrote:
This does not sound like a memory management issue to me. Like I
said, releasing an object does not set the pointers to that object to
nil. The object does not know about those pointers. If it did, then
we would have real garbage collection, not retain and release.
Either there are multiple objects involved and you think they are the
same object, or you are reinitializing the object, or there is some
other coding error. Given that you indicated it happened in another
case with several variables, I would think there is some aspect to the
coding style that is causing this.
Verify that the object address is the same for both method
invocations, and set a breakpoint on the init method(s).
Michael
On Monday, December 30, 2002, at 02:44 PM, mw wrote:
Before I respond, I'd just like to let the rest of the people on the
list
know that this controller is NOT a delegate. The purpose of the
controller
is to supply external information to the custom control when the
control
asks for it. The reason I have to use this is because this code is
going to
be turned into a reusable framework that I can use in all of my future
applications. Hence the use of a protocol and the reason for not
using a
delegate.
Btw, I also had previously set the program up to request all of the
information from the controller at once (and store those NSImage
objects in
member variables), and then use them when the appropriate event
methods were
called. But this too didn't work because, whenever an event method was
called, all of the NSImage objects were <nil>, just like what is
happening
in this case. I doubt it is a one time thing such as a typo or an
inconsistency with the controller because of this same strangeness
occurring
the first time I tried it.
On 12/30/02 4:55 PM, "Kevin Callahan" <email@hidden> wrote:
Hi -
I highly recommend reading the memory management articles on
Stepwise.
I've included links to them in my Accessorzier app, an app which
shows
you many memory management techniques used by Cocoa/ObjC experts.
http://www.versiontracker.com/dyn/moreinfo/macosx/16347
The app looks great... but where's the documentation? ;-).
Also, I have already read the memory management articles on Stepwise
(I
actually reread them after sending out my first post regarding this
issue,
and it didn't help any).
Here's one way to write the set method:
- (void)setController:(id <NPRolloverProtocol>)aController
{
[aController retain];
[controller release];
controller = aController;
}
but there are many other, depending on what you are doing.
I tried adding in the line that releases controller first, but it
didn't
seem to have any effect. -mouseExit was still pulling <nil>'s.
Also, in your mouse entered method, you might get your controller
using
an accessor method instead of calling it directly (assuming you have
an
accessor for getting the controller):
overState = [[NSImage alloc] initByReferencingFile: [mainBundle
pathForResource:[[self controller] getOverStatePath:self]
ofType: [[self controller] getOverStateType:self]]];
Well, I don't need to use an accessor method to access controller
because
the only functions that directly reference it are already in the class
anyway. What point would there be to making an accessor method?
If you want a controller to live for the life of the application,
then
you might want to create a singleton controller ..
so that there's only ever the existence of one controller object.
Do you know how to do that?
Ooh, that sounds interesting. I have never heard of a singleton
controller.
Please explain if you think it could possibly resolve this problem.
Thanks,
mw
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.