Thank you all for hammering this down, maybe I needed it :) I completely forgot about the unique superview thing, and didn't know about the actual bit sharing that UIImage could perform, both of which do settle my use case as a no-no. Thanks.
>> Now in *another* nib file I have *another* controller and I wanted to tell >> it: >> "BTW the image you want is in nib file 1, object id 789" > > That makes no sense because no one would (or could?) keep an *image* in a > nib file. An image is not the name of a class; it is a real thing, a > resource, an asset; it would be in the app bundle and you'd refer to it with > imageNamed: or similar. As should have been clear with "nib file 1, object id 789" I was referring to *references* certainly not image data, that I'm not dumb enough to believe that IB would somehow "slurp" from the file system and include as an XML binary blob!!! > Also let's make sure you understand about the file's owner. Every nib file > has an owner when it is loaded. The owner is an instance that already exists > before the nib is loaded, and it is represented inside the nib by a proxy > object. That's why you can have outlets to or from the file's owner even > though it isn't instantiated from the nib. So if the same object needs to > see stuff that comes from two different nibs, you could make it the owner / > loader of both nibs - though that would be very unusual. A better way is to > start with two instances that can see each other and have one load nib 1 and > the other load nib 2. Another possible architecture is that nib 1 is loaded > and one of the resulting instances then loads and is owner for another nib - > so now that instance, which was instantiated by loading of nib 1, can have > outlets to things instantiated by loading nib 2. This is very true and I am not disputing that. Since I have been convinced that even trying to share the image _bits_ was futile, I won't attempt this anymore. Anyway, thanks again to all -- JFB _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
