mikeash.com pyblog/friday-qa-2010-04-23-implementing-a-custom-slider.html comments

mikeash - 2010-06-13 18:34:42

Sun, 13 Jun 2010 18:34:42 GMT

It's interesting that Apple recommends this approach, since virtually every Apple control takes the inner event loop approach. And since we already have to code around that when thinking about when our timers and such fire (by e.g. adding them to NSEventTrackingRunLoopMode if we want them to fire during control tracking) then having third-party controls do the same thing really doesn't add any difficulty.

DavidPhillipOster - 2010-06-12 19:42:19

Sat, 12 Jun 2010 19:42:19 GMT

pardon me, should be: mouseDragged: above, not mouseMoved:
Here's the working code:



@interface DiagonalTracker : NSObject {

  DiagonalSlider *owner_; // WEAK

  double valueOffset_;

}

- (id)initWithOwner:(DiagonalSlider *)owner offset:(double)offset;



- (void)mouseDragged:(NSEvent *)theEvent;



@end

...

#pragma mark Event Tracking



- (void)_trackMouseWithStartPoint: (NSPoint)p {

  // compute the value offset: this makes the pointer stay on the

  // same piece of the knob when dragging

  double offset = [self _valueForPoint: p] - value_;

  [self setTracker:[[[DiagonalTracker alloc] initWithOwner:self offset:offset] autorelease]];

}



- (void)mouseDown: (NSEvent *)event {

  NSPoint p = [self convertPoint: [event locationInWindow] fromView: nil];

  

  if([[self _knobPath] containsPoint: p]) {

    [self _trackMouseWithStartPoint: p];

  } else if([self _sliderContainsPoint: p]) {

    [self setDoubleValue: [self _valueForPoint: p]];

    [self sendAction: [self action] to: [self target]];

    [self _trackMouseWithStartPoint: p];

  }

}



- (void)mouseDragged:(NSEvent *)event {

  [tracker_ mouseDragged:event];

}



- (void)mouseUp:(NSEvent *)event {

  [self setTracker:nil];

}



...

@implementation DiagonalTracker



- (id)initWithOwner:(DiagonalSlider *)owner offset:(double)offset {

  self = [super init];

  if (self) {

    owner_ = owner;

    valueOffset_ = offset;

  }

  return self;

}



- (void)mouseDragged:(NSEvent *)event {

  NSPoint p = [owner_ convertPoint: [event locationInWindow] fromView: nil];

  double value = [owner_ _valueForPoint: p];

  [owner_ setDoubleValue: value - valueOffset_];

  [owner_ sendAction: [owner_ action] to: [owner_ target]];

}



@end

DavidPhillipOster - 2010-06-12 19:00:23

Sat, 12 Jun 2010 19:00:23 GMT

RE: mouseDown:/mouseUp: methods

Apple recommends you use separate mouseDown: mouseMoved: mouseUp: methods rather than a while loop, since the while loop technique can block other event processing that this part of the program may not know about (events from other sources, timers firing.)

I like to wrap my mouse handling up into a Gesture object, which becomes firstResponder, and is responsible for that gesture. Although for a simple slider, the extra complexity isn't worth it: just put the mouseDown: etc methods in the in the view.

Now if it also had clickable named tick-marks, or had multiple thumbs for displaying an interval, or had a text readout that you could type at during the mouse track, then helper objects might make the code more comprehensible.

Ben Cohen - 2010-05-20 10:48:30

Thu, 20 May 2010 10:48:30 GMT

Another great post, thanks!

Could you give a bit more info regarding event handling? I've a always handled events with the mouseDown:/mouseUp: methods but the alternative approach you descibe seems much cleaner. This makes me think that there's more to event handling in general than I was aware of.

steve - 2010-04-25 03:20:33

Sun, 25 Apr 2010 03:20:33 GMT

mikeash: I believe one of the most difficult skills to learn as a programmer is to be able to differentiate between the work the computer does and the work the programmer does.

Damn, you nailed my problem right there!

mikeash - 2010-04-24 02:41:12

Sat, 24 Apr 2010 02:41:12 GMT

nevyn: I believe one of the most difficult skills to learn as a programmer is to be able to differentiate between the work the computer does and the work the programmer does. It's so common to see someone reject an idea that makes the computer work harder, as if they thought it would be more difficult for them to write it.

For something like a custom control, the easiest approach is to build a single drawing method which can draw the current state of the control, and when the state changes, redraw. This minimizes the amount of code you have to write, because all drawing is the same, and reflecting state changes in the GUI is a one-liner to invalidate the view. This approach is more work for the computer, but it rarely matters.

Using CoreAnimation will be less work for the computer (no expensive redraws just for moving elements around) but more work for you, because you have to do a lot more setup, then go through a different code path to reflect state changes.

(CoreAnimation could easily be a net win if you actually want, say, animations. But for a simple control like this, I can't see any reason to use it.)

Ben Mitchell: A great question! I'm not sure of the specifics, but you'd want to implement one or more of the methods in the NSAccessibility informal protocol. Probably -accessibilityAttributeValue: to tell Accessibility what type of control it is and its current value, and then the corresponding setter to allow its value to be set.

foobaz: Yes, hypot would be better here, I just forgot about it. The math.h header is full of great little helpers like this. (For others reading this, helper functions like hypot aren't just convenient, but they usually produce an answer with better precision than you get by writing the calculation out longhand.)

foobaz - 2010-04-23 19:09:05

Fri, 23 Apr 2010 19:09:05 GMT

In your len() function, you compute the magnitude of the vector with sqrt(p.x * p.x + p.y * p.y);. I prefer to use the underappreciated hypot() function, like hypot(p.x, p.y).

Ben Mitchell - 2010-04-23 18:53:20

Fri, 23 Apr 2010 18:53:20 GMT

What additional work would be needed to make this control present itself as an AXSlider to Accessibility?

nevyn - 2010-04-23 17:59:46

Fri, 23 Apr 2010 17:59:46 GMT

Any opinion on using Core Animation instead of drawRect/CG? I usually do that when writing custom controls, but often find it tedious; feels like it's at least as much work adjusting existing state (layers) as just redrawing everything when there's a change.