I'm not sure how I would get NSToolbar to use my subclass of NSToolbarView. I
can't set the class of the toolbar *view* itself in IB (nor programatically, as
far as I know), because NSToolbarView is a private class that NSToolbar uses to
implement the UI. I can of course change the class of the NSToolbar object
itself to a subclass, but this wouldn't help me much as there is no public
NSToolbar method that allows me to change the class of its view.
On 2011-08-25, at 9:35 PM, Quincey Morris wrote:
> On Aug 25, 2011, at 19:48 , Indragie Karunaratne wrote:
>
>> Based on Corbin's tip, I overrode -hitTest: on NSToolbarView to call
>> NSView's implementation instead and suddenly everything works. I expected
>> something to break in NSToolbarView from doing this, but I've tested pretty
>> thoroughly and there seem to be no issues. I don't know exactly how
>> dangerous this is because I don't know what NSToolbarView's implementation
>> of hitTest: is, but so far no issues.
>>
>> @interface NSToolbarView : NSView
>> @end
>>
>> @interface NSToolbarView (RightMouse)
>> @end
>>
>> @implementation NSToolbarView (RightMouse)
>>
>> - (void)hitTest:(NSPoint)aPoint
>> {
>> [super hitTest:aPoint];
>> }
>>
>> @end
>>
>> That said, would my application get rejected from the Mac App Store for
>> overriding *public* methods of a *private* class via a category? I could
>> achieve the same result by checking the class and swizzling NSView's
>> implementation of -hitTest:, but if I could get away with this it would be a
>> lot easier (and cleaner).
>
> I think it's a misstatement to say that you "overrode" 'hitTest:'. In Obj-C,
> overriding conventionally means supplying a subclass implementation that
> takes the place of the superclass implementation. What you actually did was
> to *replace* 'hitTest:'. However, if you want to treat this as a quibble over
> usage, that's fine.
>
> The real problem with your approach is that it's a bit dangerous. You don't
> *know* that NSToolbarView's own override of 'hitTest:' isn't itself
> implemented in a category. If it is, then you are competing for the role of
> replacer, and you might lose.
>
> A better approach (if it's possible -- which it may not be if IB makes things
> hard for you) is to subclass NSToolbarView, and change the toolbar's class in
> IB after adding it to the window. (If you're creating the toolbar entirely
> programmatically, it's more straightforward, of course.) Then you can
> *really* override 'hitTest:', in the normal subclass way.
>
> Finally, although you haven't seen any side effects of throwing away the
> NSToolbarView implementation of 'hitTest:', which is what the above code
> does, you don't know what else you might have broken. It would be safer to
> put code in your override to test directly for your custom toolbar item view,
> and send the message directly to your view if it's the one under the mouse.
> If not, call the NSToolbarView method, not the NSToolbarView super method.
> Again, this is easiest to do if you're actually using a NSToolbarView
> subclass.
>
>
_______________________________________________
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 arch...@mail-archive.com
