Re: Stop NSScrollView from catching scroll events.
Re: Stop NSScrollView from catching scroll events.
- Subject: Re: Stop NSScrollView from catching scroll events.
- From: Michael Ash <email@hidden>
- Date: Mon, 23 Mar 2009 23:48:05 -0400
On Mon, Mar 23, 2009 at 6:09 PM, Ben Lachman <email@hidden> wrote:
> On Mar 23, 2009, at 5:47 PM, Corbin Dunn wrote:
>
>> On Mar 23, 2009, at 2:35 PM, Ben Lachman wrote:
>>
>>> On Mar 23, 2009, at 10:54 AM, Michael Ash wrote:
>>>
>>>> On Mon, Mar 23, 2009 at 3:46 AM, Ben Lachman <email@hidden> wrote:
>>>>>
>>>>> I have a tableview that's neatly wrapped in a scroll view by IB. I
>>>>> manually
>>>>> resize the scrollview whenever a row is added to the tableview so that
>>>>> all
>>>>> the row are always visible. Thus I basically don't need a scroll view.
>>>>> However even though it can't actually scroll the tableview it still
>>>>> eats
>>>>> scroll events when the mouse is over it. I tried ripping the tableview
>>>>> out
>>>>> of the scroll view programatically, but that didn't yield useable
>>>>> results.
>>>>> Is there a straight forward way to have a scroll view pass scroll
>>>>> events on
>>>>> up the responder chain?
>>>>
>>>> Just subclass NSScrollView, and override -scrollWheel: to call
>>>> directly through to NSResponder's implementation and bypass
>>>> NSScrollView's implementation.
>>>
>>> I was thinking this was easy, but now I'm not so sure.
>>>
>>> How do you call through to some arbitrary class in a class's inheritance
>>> chain?
>>
>> It's definitely the way to do it.
>>
>> Just send it on to [self nextResponder]. that's all!
>
> Ah! Thanks Corbin. Thats the right (and easy) way to do it.
>
> For the record, this works too (and supports tiger, I'm not sure if Kyle's
> code does):
>
> - (void)scrollWheel:(NSEvent *)theEvent {
> void (*responderScroll)(id, SEL, id);
>
> responderScroll = (void (*)(id, SEL, id))([NSResponder
> instanceMethodForSelector:@selector(scrollWheel:)]);
>
> responderScroll(self, @selector(scrollWheel:), theEvent);
> }
Right, that would be my preferred way of doing it. I like to use the
NSObject methods rather than the ObjC runtime functions where I can,
since the NSObject methods are usually friendlier and more broadly
compatible.
As to the question of doing this versus simply manually sending the
message to the next responder, it's really just a question of
preference here. I like letting the existing code handle things, but
since this particular method is so simple, and its documentation
precisely states what it does, it really makes no difference here. For
something where the super-superclass does something more complex, this
technique would have a significant advantage.
Mike
_______________________________________________
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