4

THE PROBLEM:

I have an NSScrollView. I'm using it to implement a custom "Table View" with rows of data that are actually NSViews. (Note: this is not an instance of NSTableView.)

As I scroll vertically (there is no horizontal scrolling), I use a boundsChanged notification to add (as subviews of the scrollView's contentView) the NSViews that become visible (the ones with frames that intersect the scrollView's document visible rect) and to remove the ones that are no longer visible (frames outside of the scrollView's visible rect.)

The process works wonderfully except when it comes to inertial scrolling. If I have my cursor over cell X and I flick the trackpad to scroll downwards FAST with inertia, cell X quickly leaves the visible rect and, as such, is removed from the scrollView's contentView. BUT, that kills inertial scrolling. If I do NOT remove cell X as a subView, then inertial scrolling works perfectly.

WHAT I NEED:

A way to keep inertial scrolling while still removing the NSView that the cursor happened to be on top of when the user started the scrolling gesture.

WHAT I'VE TRIED:

I've looked at NSResponder's method:

-scrollWheel:(NSEvent *)theEvent

The default implementation passes scrollWheel to the next responder. So, I subclassed NSScrollView and implemented this method to try to stop it from passing the scrollWheel event to the individual subViews inside the scrollView's contentView. Didn't work.

So then I went into my NSViews (the ones I'm adding to the contentView) and overrode scrollWheel to pass the event back to the scrollView itself. Didn't work.

I still get scrolling in both cases, but not with inertia.

Any ideas? Thanks!

Bryan
  • 4,628
  • 3
  • 36
  • 62
  • When you say "implement a standard 'Table View'", do you mean you're using an `NSTableView`? – jscs May 28 '11 at 00:58
  • No, I mean I'm rolling my own custom "table View." The official NSTableView class is... outdated (to be nice about it.) So I'm creating my own "table view" by simply adding/removing NSViews to a scrollView as the user scrolls. – Bryan May 28 '11 at 01:54
  • The way to do this on iOS is to use a delegate, but sadly there's no such delegate for NSScrollview to detect when it stops/starts. – Mitchell Currie Aug 10 '11 at 01:51
  • Did you find a solution for you problem. I ran exactly into the same problem (with the only difference, that I'm scrolling only horizontal). I was thinking about removing the subviews not before the scroll view did finished scrolling. – Tobias Kräntzer Feb 27 '13 at 21:51
  • Hey Tobias. No, I never did. This was before Lion came out. When Lion shipped with the *vastly* modernized NSTableView class, I simply used that instead. – Bryan Feb 28 '13 at 09:11

1 Answers1

0

I haven't done this exact thing in Cocoa, but I'd probably be thinking about simply recycling your NSView object, as soon as its off the visible rect, by removing its subviews, then changing its frame to be in place to scroll back onto the visible rect from the top.

You can obviously do this by simply updating its frame, and avoid having to remove and re-add it to the NSScrollView.

Jonathan Watmough
  • 879
  • 9
  • 12