On 28 Nov 2008, at 4:08 am, Graham Cox wrote:
On 28 Nov 2008, at 3:18 am, Michael A. Crawford wrote:
I assume I can sub-class the control but I wondering if there is a
better way. I'm using a circular slider and would like it to
rotate when I roll the scroll wheel up or down.
You can just implement the -scrollWheel: method in a category.
Playing with this, the code below gives a nice "feel" for a big
variety of sliders in my app and wraps properly with circular ones
too. I was skeptical at first that this was a good idea but trying it
out in the app I've quickly come to appreciate how usable it is in
practice!
@implementation NSSlider (Scrollwheel)
- (void) scrollWheel:(NSEvent*) event
{
float range = [self maxValue] - [self minValue];
float increment = (range * [event deltaY]) / 100;
float val = [self floatValue] + increment;
BOOL wrapValue = ([[self cell] sliderType] == NSCircularSlider);
if( wrapValue )
{
if ( val < [self minValue])
val = [self maxValue] - fabs(increment);
if( val > [self maxValue])
val = [self minValue] + fabs(increment);
}
[self setFloatValue:val];
[self sendAction:[self action] to:[self target]];
}
@end
Please don't do this! It will apply to every single slider in your
process, even ones you didn't create yourself,
Well, that is potentially a "feature". I guess the point would be to
test your UI thoroughly and make sure it was what you wanted
*everywhere*. But if that was what you wanted, doing it in a subclass
would be more awkward, since you might not be able to "get at" every
instance in the UI (e.g. the opacity slider in NSColorPanel) to set
its class, especially now that -poseAsClass: is out of bounds.
and if at some point
Apple adds their own -scrollWheel: implementation, it will end up
fighting with yours and it's not guaranteed whose will win.
Yep, that's a potentially more serious issue. It would be nice if a
category had a way to check for an existing implementation and quietly
no-op itself. Just checking respondsToSelector: doesn't work of
course, always returning YES.
Right now, overriding methods in a category is not only legal, but
documented as supported. Either Apple should come right out and say
this is not allowed or rig the runtime to prevent it. As long as it's
legal and documented as such, the judgement as to whether to add
functionality in this manner rests with the developer. What's the
point of a runtime feature you can't ever use?
It's much
better to simply subclass NSSlider and use your subclass anywhere you
want a scroll-wheelable slider. I'm not sure why the OP is averse to
subclassing, unless he's just asking if there's any built-in
functionality already there. It's going to be perhaps ten lines of
code and will get the job done.
I agree, subclassing is definitely the safer option and amounts to the
exactly same code, but a little bit more effort to set the class in IB.
--Graham
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
