Re: rightMouseDown: never called in NSView subclass
Re: rightMouseDown: never called in NSView subclass
- Subject: Re: rightMouseDown: never called in NSView subclass
- From: Indragie Karunaratne <email@hidden>
- Date: Fri, 26 Aug 2011 10:36:48 -0600
Thats actually what I'm doing right now, its an NSToolbarItem with a custom view but like I said, the right mouse events are not passed to it by NSToolbarView without that little hack. I could, as you said, circumvent NSToolbar completely, but when a view is placed outside of the toolbar, it disappears when Lion goes into fullscreen mode. I don't know if this is a bug or intended behaviour.
On 2011-08-26, at 12:03 AM, Mark Munz wrote:
> The description of what you're trying to do is a bit vague, but
> couldn't you just create an NSToolbarItem with a custom view? You
> might need to do a few tweaks if it needs to resize with the window,
> but that sure seems easier than trying to circumvent the framework as
> you are describing. You'd be able to do virtually anything you want in
> that custom view and you wouldn't be necessarily fighting the
> framework.
>
> Alternatively, you could just create a custom view that is placed at
> the top of your content view of the window and just ignore the
> NSToolbar class completely.
>
>
> On Thu, Aug 25, 2011 at 9:46 PM, Indragie Karunaratne
> <email@hidden> wrote:
>> Is there any other way to do this aside from what I'm doing right now? As far as I know, I have two choices:
>>
>> a) Use this method and risk something breaking
>> b) Write an NSToolbar clone
>>
>> I know the risks, but if I could get this to pass through Mac App Store submission then I'd rather deal with possibility of something breaking later on that than to rewrite NSToolbar. The one last thing I can think of is to use the ObjC runtime to retain the original implementation, swizzle hitTest: and check whether my view is under the cursor, and if not, just call the original implementation. However, method swizzling always feels like a dirty workaround so I'm not sure if it would be much better than this (and if it would be acceptable in the MAS).
>>
>> On 2011-08-25, at 10:40 PM, Quincey Morris wrote:
>>
>>> Ah, well, yes, if IB doesn't expose the class you need, that makes subclassing impractical. But in that case, replacing the NSToolbarView method seems even more undesirable.
>>>
>>>
>>> On Aug 25, 2011, at 20:55 , Indragie Karunaratne wrote:
>>>
>>>> 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.
>>>
>>>
>>
>> _______________________________________________
>>
>> 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
>>
>
>
>
> --
> Mark Munz
> unmarked software
> http://www.unmarked.com/
_______________________________________________
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