Fwd: display an image in a button
Fwd: display an image in a button
- Subject: Fwd: display an image in a button
- From: email@hidden
- Date: Fri, 20 Feb 2004 04:35:23 EST
Yes Louis, you have made it much clearer, thank you.
Return-Path: <email@hidden>
Received: from rly-xh05.mx.aol.com (rly-xh05.mail.aol.com
[172.20.115.234]) by air-xh01.mail.aol.com (v98.6) with ESMTP id
MAILINXH11-4ac4033d4152c5; Wed, 18 Feb 2004 16:08:44 -0500
Received: from sara.dreamhost.com (sara.dreamhost.com [66.33.193.59])
by rly-xh05.mx.aol.com (v98.5) with ESMTP id
MAILRELAYINXH56-4ac4033d4152c5; Wed, 18 Feb 2004 16:07:33 -0500
Received: from [66.81.113.225] (host-66-81-113-225.rev.o1.com
[66.81.113.225]) by sara.dreamhost.com (Postfix) with ESMTP id
85CA29F10F; Wed, 18 Feb 2004 13:07:42 -0800 (PST)
Mime-Version: 1.0
X-Sender: email@hidden
Message-Id: <
p04310100bc5979d68dee@[66.81.79.7]>
In-Reply-To: <
email@hidden>
References: <
email@hidden>
Date: Wed, 18 Feb 2004 13:06:28 -0800
To: email@hidden
From: "Louis C. Sacha" <email@hidden>
Subject: Re: display an image in a button
Cc: email@hidden
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-AOL-IP: 66.33.193.59
X-Mailer: Unknown (No Version)
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.