views:

1006

answers:

3

Unfortunately this is hard for me to test myself because I have yet to get a Magic Mouse of my own, but I've been told by my testers who do have a magic mouse that momentum scrolling isn't working in my app. I've not subclassed NSScrollView, but scrollview's document view is all custom. I have not overridden scrollWheel: anywhere, either, and yet momentum apparently just isn't working. I'm not even sure where to begin. I thought it'd just send scrollWheel events and things would take care of themselves. (Scrolling with a wheel or on the MBP trackpad works as expected.) Obviously I must somehow be doing something that's stopping it, but I don't even know where to begin. Thoughts?

+1  A: 

Odd scrolling behavior can occur when you don't set the Line Scroll and Page Scroll properties of the NSScrollView itself.

Beyond that, you're quite simply going to have to get a Magic Mouse - easily said or not :-) - to test this yourself or post the entire code of your custom view as well as the xib containing it. There's no way others can offer you more than guesses (like the above) without it.

Joshua Nozzi
A: 

I'm having the same issue as the poster. I have an identical setup: A custom view set as the document view of an NSScrollView. My NSScrollView is not a custom subclass and I haven't done any intentional tinkering/overriding of normal scroll behavior. Momentum scrolling in this scroll view does not work.

I, however, do have a Magic Mouse to test with. :)

Does anyone have any info on what needs to be done to achieve momentum scrolling? perhaps override -scrollWheel: in my custom view (the document view) and perform some logic there?

Todd Ditchendorf
See my own answer below. I eventually figured out what was going on. Your situation may be slightly different, but I'd bet you are somehow running into the same thing I was running into - especially if you come from an iPhone programming background like I did. :P
Sean
+2  A: 

I figured this out awhile ago and the problem was that on scroll, I was doing a lot of fancy view manipulation somewhat like how on the iPhone the UITableView adds and removes views as they scroll on and off screen. This worked great for performance - but the more I got into OSX programming, the more I realized this was wrong for OSX (but the right idea of iPhone).

Anyway, what's really going on, it seems, is that when you do something like a wheel scroll, the scroll event is sent to the view that's under the mouse cursor and then it ripples down the responders/views until it gets somewhere that handles it. Normally this isn't a problem, but with momentum scrolling the OS is really just sending ever smaller scrollWheel events to the view that was under the cursor at the time the momentum started. That means if the view is removed during the course of scrolling (because it scrolls off screen or something), it breaks the chain and the momentum stops because the view that's still getting the scrollWheel messages is no longer in the view hierarchy.

The "simple" fix is to not remove the view that got the last scrollWheel event - even if it's off screen. The better fix (and the one I went with) is to not try to use NSViews like they are UIViews and instead just draw the content using drawRect. :) Not only is that about a billion times faster, it Just Works(tm) with momentum scrolling because it's how OSX expects things to be done.

Repeat after me: OSX is not iPhoneOS.. :P

Sean
sean, thanks for the insights. very helpful. you were right about the root cause... i had implemented a UITableView-like view for the desktop, and removing the 'cell' views from the hierarchy was causing the issue. However, i have to disagree that this is a bad strategy for the desktop. after reading your post above, i found a simple fix for the issue: dont remove a view that is about to be reused from its superview. just resize/reposition it. and then remove those that are not reused. problem solved. seen in action here: http://tod.nu/listview
Todd Ditchendorf