This has been dealt with at length, as far as I can tell, but going back to 
your original post, here's my threepenn'orth...


On 06/06/2010, at 7:14 AM, Jean-François Brouillet wrote:

> Hi.
> 
> Consider the situation where I have a "root" ImageView in IB.
> I specify the actual image I want it to hold by just filling/
> selecting which of the existing images are already present in the
> project, using the "Image" input box of the Image View Attributes
> inspector.

This works because [NSImage imageNamed:<blah>] is able to search a variety of 
locations it knows about to try and locate the image file by name. It does not 
work by referencing objects across nibs.

> Then I can just set the titleView outlet of some navigationItem
> elsewhere in the same nib file, and voilà, my image is displayed
> at runtime exactly where I want I, when I want it.
> 
> But now I create a second nib file for a second controller, and
> I really would like to display the same image in the same kind
> of setup.

You can do that - just specify the same image name in the IB inspector. Because 
of the way images can be loaded by name from resources, this works, and shares 
the image instance so loaded.

> Problem is: I haven't figured out whether it is possible at all
> for nib file#2 to refer to any object inside nib file#1,

No, you can't.

> hence
> I have to either pay the memory cost of a duplicate object in
> the second nib file,

The cost is absolutely minute and not worth sweating. The image (as loaded, in 
memory and possibly cached as a bitmap) might have some considerable cost which 
would be worth not duplicating across instances of that image. Luckily, NSImage 
does that for you pretty much by default. Avoiding the duplication of an image 
VIEW on the other hand, is simply not worth the trouble. The code needed to 
avoid duplicating the instance, even if it could be made to work without bugs 
(unlikely) would swamp the saving you'd gain.

> or forget about nib files entirely and do
> the whole wiring by hand with code, which kind of defeats the
> purpose of separate nib files in the first place.

Not really. The purpose of separate NIB files is not to avoid duplicating 
instances of lightweight interface objects.

> So ... is there a way to refer to NIB1.objA from NIB2.objB ?

No, with the exception of known shared objects such as the NSApplication 
instance or its delegate. It's also possible to add shared singleton objects to 
a NIB file in some cases but it's a slightly more advanced use which isn't the 
same as what you think you mean by "singleton". (e.g. Sparkle's main object is 
a singleton and is typically added to the MainMenu NIB file).

> 
> Bonus question: is it possible at all to refer to nib files
> (while staying within IB) outside of the main project directory?
> I tried variations on ./rsrc/mynib2 or rsrc/mynib2 in the NIB Name
> input field to no avail ...


No.

> I plainly understand that I can spread my NIB files all over the
> place (almost :-) if I go the coding route, but I'd rather do
> everything I can in IB if that's possible ...

Just pull your interface objects together as you want them in each nib and 
forget about trying to share them across NIBs or different instances of the 
window in your app. It's pointless, premature optimisation and unsupported 
anyway.

Object IDs and names within IB are not visible to your code. The name is an aid 
for you to identify an object, I guess the ID might have some similar purpose 
but as far as I can tell it's an IB internal implementation detail and I'm not 
sure why it's even exposed to the user.

General advice would be to stick to conventional approaches until you know the 
stuff so intimately that "clever" shortcuts could be worth considering, but 
then only if they can be proven to have some real benefit. What you're 
attempting is not only unconventional (which is why it seems difficult - a big 
clue there) but you have not shown that it would have any benefit whatsoever. 
It might be tempting to prematurely optimise in this way but resist it - it's 
the sure path to disappointment.

Sharing image instances is sensible, which is why NSImage already does that for 
you.

--Graham




_______________________________________________

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

Reply via email to