Re: Problem with multiple instances of a nib
Re: Problem with multiple instances of a nib
- Subject: Re: Problem with multiple instances of a nib
- From: PCWiz <email@hidden>
- Date: Sun, 22 Nov 2009 15:49:29 -0700
Good to know that I'm not the only one experiencing this. The easiest
solution I guess is to keep an array of the controller objects, which
I will try. Is this how you mean:
NSMutableArray *controllerObjects = [[NSMutableArray alloc] init];
ImagePanelController *newController = [[[ImagePanelController alloc]
init] autorelease];
[controllerObjects addObject:newController];
With this method, when the panel is closed would the controller be
removed from the array (I'm guessing not, and if so, how would I make
it do that?)
On 2009-11-22, at 3:32 PM, Ben Haller wrote:
On 22-Nov-09, at 5:06 PM, PCWiz wrote:
I have a separate XIB in which there is an NSPanel containing an
image view to set an image. When I call a method, it creates a new
instance of the controller for the nib, loads the nib, and then
sets the image of the image view via the controller object. Like
this... The problem is, once I call the method again to create
another instance, the new panel pops up, and within seconds any
existing instances of the panel just vanish. I have no idea what
I'm doing wrong, I have GC turned on, could that be the problem?
This same thing has been biting me. The problem is, I am guessing,
that nothing in your code keeps a strong reference to your
controller. Making a window with a controller creates an isolated
group of objects that are not referenced from the outside, so they
are collected when the collector gets around to it.
The fix is that something else in your application, like perhaps
your app delegate object if there isn't a more logical place, has to
keep an array of controllers, for the sole purpose of generating
strong references to them, OR you have to force your controller to
be immune to GC by calling CFRetain on it (and then CFMakeCollectable
() when the window it controls closes, presumably). The former
makes your controllers owned objects, belonging to the app delegate
or whatever other object; the latter makes it semantically clear
that the controller is responsible for its own lifetime, and may be
considered a root object. Which pattern is better in your case
would depend on the design of your app.
If you look back a couple of weeks, you'll find posts by myself and
others about this. I initially felt there was a bug (or more
precisely a design flaw) here somewhere, but I was eventually
convinced (browbeaten into submission?) by the list that this is all
as it ought to be...
Ben Haller
Stick Software
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden