On Feb 20, 2011, at 00:17, Andy Lee wrote: > On Feb 19, 2011, at 7:48 PM, Quincey Morris wrote: > >> I think the only way to fix this is to override the appropriate >> 'scrollWheel:' event method, and to pass the event on up the responder chain. > > I have the same requirement as the OP: a scroll view that never needs to > actually scroll, but which nevertheless eats scrollWheel: events, which keeps > *its* containing scroll view from getting them. My solution was exactly as > you describe. For the inner scroll view I use a subclass of NSScrollView that > overrides scrollWheel: by sending scrollWheel: to its nextResponder, causing > the outer scroll view to eventually get it. You can use IB to set the class > of the inner scroll view to the subclass.
For completeness, I should amend my statement: the alternative way suggested by Peter Lübke (creating the NSTableView programmatically without an enclosing scroll view) sounds viable too. OTOH, I guess you could avoid having to create and configure the table in code (possibly quite a bit of code) if you use IB to place the table, and then remove the enclosing NSScrollView from the view hierarchy in code. It's probably about the same amount of code as your solution, I dunno. > I notice WebKit does the expected thing with nested scroll views (for example > in a typical web mail window in Safari). This includes cases where the inner > scroll view *can* scroll. I actually find this annoying. In *this* case I'd > prefer the scroll wheel to stop dead at the top or bottom. It's a Fitt's Law > kind of thing for me; I want to be able to scroll, scroll, scroll to the > bottom of a list and not have to be careful about scrolling so much that I > shift the whole window contents around. But maybe arguments could be made the > other way. I hate that too. And the reverse: sometimes I want to scroll the window but end up scrolling a text field instead. Perhaps the real answer is that nested scrolling views just have *terrible* usability, period. Or perhaps the best that could be done is for scroll views to pass scrollWheel events up the responder chain *if* there's another scroll view further up the chain (so that the scroll wheel is handled at the highest possible level) *except* if the scrollWheel event is directly over a view's scroll bar, in which case it would be processed by the scroll view that the scroll bar belongs to. Would that work better? (The discoverability wouldn't be great, though.) _______________________________________________ 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
