Really? Outside of things like buttons, that's an unfortunate choice,
isn't it? As the "Cocoa Event-Handling Guide" points out, a class
that handles dragging in this manner is "more difficult to extend
without the subclass reimplementing all the dragging code".
Absolutely. I don't use PDFView but I had to do some unpleasant
things when sub-classing NSTextView (which behaves the same way). I
was under the impression that this was a NextStep holdover and that
new things wouldn't do it.
It turns out that, for tracking in any event, a lot of state has to be
kept (instance vars) in order to handle dragging or tracking across
the three event flavors.
So? So keep it. What is the problem? If you're worried about the
allocated size of the object, put your state information in a struct
and allocate it on mouseDown and free it on mouseUp. That way you
only increase the size of the object by a few bytes. The other way
really limits the usefulness of the object because you can't subclass
it properly. (Not to mention confusing beginners who look at the
docs, see a subclass of NSResponder and wonder why their methods
never get called.)
Robert Clair
_______________________________________________
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
