• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: display an image in a button
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: display an image in a button


  • Subject: Re: display an image in a button
  • From: "Louis C. Sacha" <email@hidden>
  • Date: Wed, 18 Feb 2004 13:06:28 -0800

Hello...

Would it not make more sense if it obtained everything from the the main
bundle or the preferencePane bundle?

How can it be selective and what decides where information comes from?

Well, each situation is different, and each method that does some kind of information or resource lookup tries to do it in a way that should work correctly most of the time. There will always be cases where it does the opposite of what you want it to, so that's why it's important to understand exactly what those methods are doing, and in general the documentation is fairly good. For example, the documentation of NSImage's imageNamed: method describes the process used to try to locate an image if there isn't one registered by the name provided. In most cases, checking the main bundle for the resource is the default behavior, but not always.


Obviously your first approach solves the problem if I really need it to load
the images from the bundle but is their any reason why I shouldn't do this or
is this an acceptable practice?

It's a perfectly acceptable practice to load images and resources from bundles, and it's part of the reason bundles work the way they do.


To make your suggestion a little more transportable, I would assume that this
is valid
NSString *imagePath = [[NSBundle bundleForClass:[self class]]
pathForImageResource:some_image];
and will always load the image from the calling bundles resource folder?

To clarify, the line above just gets the path to image, and the second line (with NSImage ... initWithContentsOfFile:) actually loads the image. In general, using [self class] instead of [YourClassName class] will work. There are cases where it won't work, but they only occur in very complex situations (for example, if you had a class BaseClassA which used [self class] to lookup the bundle for the image, and the image and the BaseClassA were located in BundleA, and then you had a class OtherClassB that is a subclass of BaseClassA and is located in BundleB, when the inherited method that used [self class] was called it would cause the wrong bundle (BundleB) to be searched for the image instead of BundleA). As a general rule of thumb (that I use), when you are dealing with writing frameworks and loadable bundles, if the resource is always going to be in the same bundle as a specific class and there is no reason for a subclass to use a different resource, it't better to hard code the name of the class using [YourClassName class] instead of [self class], even though it makes the code less reusable.


Back to my first problem, why did the missing images from the main bundle not
through up some kind of flag?

I would have thought that not being able to load an image because it's
missing would generate some kind of error but at no time did any error appear in the
run window.

As Ryan pointed out before, you were getting a type of error flag, since the imageNamed: method was returning nil because it could not find the image. In objective-C, nil is returned in many cases where an error is possible or expected, instead of raising exceptions. This allows the programmer to check the return value, and if it is nil then handle the problem without having to use an exception handler, which can be disruptive to the program. When you passed the nil reference to NSButton, it assumed that it meant that you wanted no image displayed.


While I am defined as NSObject <SS_PreferencePaneProtocol> and
PreferencePanes.framework is not imported or linked in any files, can my class still be
considered a subclass of NSPreferencePane?

No, your class would still just be a subclass of NSObject. The reason I pointed out the different possibilites for a subclass of NSPreferencePane is because it has a built in accessor for its bundle (the instance method bundle), which most objects don't. It just means you will need to look up the bundle using NSBundle bundleForclass: instead, since your class is not a subclass of NSPreferencePane...


Hope this helps...,

Louis



Well, enough questions for now, I'm still chewing your response as it
inspires thoughts and questions

Dale
_______________________________________________
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.

References: 
 >Re: display an image in a button (From: email@hidden)

  • Prev by Date: piped unzip (and this time it's not the wrong codesnipper)
  • Next by Date: passing arg 2 of 'NSApplicationMain' from incompatible pointer type
  • Previous by thread: Re: display an image in a button
  • Next by thread: Fwd: display an image in a button
  • Index(es):
    • Date
    • Thread