[juanpacolopez]

Hey all... I have a conundrum:

If I load an NSImage as follows:

tnetImage = [[NSImage allocWithZone:[self zone]] initByReferencingFile:[[NSBundle mainBundle] pathForImageResource:[themePlist objectForKey:currentThemeName]]];

themePlist is a property list that stores which image files correspond to which theme names... it Is properly formatted and that call DOES return proper results (i.e., the correct filename).

Now, at some point I copy a new image file into my app bundle's Resources folder. It gets copied properly, and an entry gets added to my plist that correctly identifies the filename. My problem is, no matter what I try, I can't make the image show up in an NSImageView or custom NSView class until I RESTART my app (it shows up blank until then).

My question is, what is the PROPER way to reinstantiate an NSImage alloc'ed in this manner to a newly coped image file? I've tried sending it a release message and just reallocating, but that doesn't work (the image doesn't load and the views fill in blank).

I've also tried sending it a release message and then:

tnetImage = [NSImage imageNamed:myNewImage];

but that doesn't seem to work either.

Does one have to "refresh" the index of an app bundle after you add contents to it (while the program is running) before referencing the new files? I've read the NSBundle docs pretty thoroughly and they don't offer any help.

The real kicker is that the images work. If I install a theme, exit my program, and then come back the theme is there and the images load (using the exact same procedure) perfectly. It's only after they've just been copied.

To offer a bit more detail... if I install a theme, quit my app, restart, REMOVE said theme (which does in fact delete the image from the app bundle) and then re-install the same theme immediately thereafter (which re-copies it to the bundle) it works fine. This is why I think it's a problem with the bundle rather than the image loading code.

So, any ideas?

[bewebste]

It looks like you should be using initWithContentsOfFile: in this situation rather than initByReferencingFile:. From the docs for NSImage:

- (id)initByReferencingFile:(NSString *)filename

Initializes the receiver, a newly allocated NSImage instance, for the file filename. This method initializes lazily: The NSImage doesn't actually open filename or create image representations from its data until an application attempts to composite or requests information about the NSImage.

The filename argument may be a full or relative pathname and should include an extension that identifies the data type in the file. The mechanism that actually creates the image representation for filename will look for an NSImageRep subclass that handles that data type from among those registered with NSImage.

After finishing the initialization, this method returns self. However, if the new instance can't be initialized, it's freed, and nil is returned. Since this method doesn't actually create image representations for the data, your application should do error checking before attempting to use the image; one way to do so is by invoking the isValid method to check whether the image can be drawn.

If the image can be cached because the cached size is smaller than the actual expanded size, that is, an image that is more than 72 dpi, then the original data is flushed and the cached image is used. If you resize the image either larger or smaller by less than 50%, the data is loaded in again from the file. If you expect the file to change or be deleted, you should use initWithContentsOfFile: instead.

This method invokes setDataRetained: with an argument of YES, thus enabling it to hold onto its filename. Note that if an image created with this method is archived, only the filename will be saved.