Re: PoseAsClass and NSColorWell (what Apple giveth, Apple taketh away...)
Re: PoseAsClass and NSColorWell (what Apple giveth, Apple taketh away...)
- Subject: Re: PoseAsClass and NSColorWell (what Apple giveth, Apple taketh away...)
- From: Jeff Johnson <email@hidden>
- Date: Fri, 28 Mar 2008 07:33:17 -0500
Graham,
If you're just overriding one or two methods of NSColorPanel, you
could use the technique I describe here:
http://lapcatsoftware.com/blog/2007/11/25/working-without-a-nib-
part-6-working-without-a-xib/
It uses the Apple-documented function method_exchangeImplementations
() in the Leopard Objective-C runtime, so it should be supported for
the foreseeable future.
Note that this function might not be available in the Tiger Objective-
C runtime. If you use the 10.5 SDK, that won't be a problem. If you
still need to support Tiger, however, I don't really know of any
'future-proof' technique. It's highly unlikely that Apple would or
could kill poseAsClass in a 10.5.x update, so it will continue to
work in both Tiger and Leopard, though it's already dead in the
Leopard 64-bit runtime.
-Jeff
On Mar 28, 2008, at 7:14 AM, Graham Cox wrote:
Looking through the latest docs I see that as of 10.5, +poseAsClass
has been deprecated.
This gives me a problem which it previously solved quite neatly.
Perhaps someone can help me figure out a different solution...
NSColorWell is a handy widget, and it has the useful ability to
automatically deselect other instances application-wide when the
user selects a particular instance (only one on at a time).
I have a similar widget which can also be the target of
NSColorPanel, but it is used for setting the colour of a colour
stop in a gradient-manipulation user interface. The entire gradient
control is an NSControl subclass, but each colour stop "part" of
the control is just something I draw as part of the control's
overall content. It is not practical to make each stop a subclass
of NSColorWell, at least I don't think it is...
So, when one of my stops is selected, it needs to turn off any real
NSColorWells that might be selected in the app, and vice versa. My
solution to this was to create a simple subclass of NSColorWell
that intercepted the -activate and -deactivate methods, used these
to keep track of the current well in a static and for good measure
send out some notifications about the fact that the selected well
changed. It also calls super, so the private details of
NSColorWell's mechanism are still used as normal. By using
poseAsClass to make this subclass stand in for all NSColorWells, I
can transparently hook into the "one at a time" targeting of color
wells without the application having to deliberately use the
subclass - and since the gradient widget is part of a framework
that apps can just "drop in", it works perfectly without placing
any special requirements on the user of the framework.
I note that the docs for poseAsClass state:
"A method defined by a posing class can, through a message to
super, incorporate the superclass method it overrides. A method
defined in a category can replace a method defined elsewhere by the
class, but it can’t incorporate the method it replaces."
This is EXACTLY why I'm using poseAsClass, and it's something a
category cannot accomplish (i.e. I need to call super).
One way out of this would be for Apple to compensate for the
eventual loss of +poseAsClass by adding notifications or more
methods to NSColorWell so that other bits of home-grown UI can hook
into them, but I'm not sure how to go about requesting this, and
even then I might be the only one!
So is there a better, cleaner, more future-proof approach staring
me in the face?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden