PoseAsClass and NSColorWell (what Apple giveth, Apple taketh away...)
PoseAsClass and NSColorWell (what Apple giveth, Apple taketh away...)
- Subject: PoseAsClass and NSColorWell (what Apple giveth, Apple taketh away...)
- From: Graham Cox <email@hidden>
- Date: Fri, 28 Mar 2008 23:14:32 +1100
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?
------
S.O.S._______________________________________________
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