Re: NSScrollView and NSTrackingArea woes [SOLVED]
Re: NSScrollView and NSTrackingArea woes [SOLVED]
- Subject: Re: NSScrollView and NSTrackingArea woes [SOLVED]
- From: João Varela <email@hidden>
- Date: Sun, 19 Jul 2015 16:36:37 +0100
First of all I would like to thank everybody that tried ho give me a hand. I really do appreciate it.
I also want to write this email to let people know how I solved the problem, so that the readers of this list do not have to go through a week of frustration as I have. Well, it took so long because this is a side project, and I am not working on it all the time.
For those who did not follow this thread from the beginning, the problem (bug) that I was hitting is that setting up NSTrackingArea objects in the document view of an NSScrollView works as expected except when the user begins to scroll and the inertia scrolling option is on. A way to avoid this is to turn off inertia scrolling as Muthu suggested, but then the scrolling is jumpy at best.
Here are my conclusions:
1) Using NSTrackingArea objects is fine and dandy as long as you do not change the superview and its subviews and you do not place them in a scrolling view or you do not have to add and remove subviews, sometimes in a very dynamic way as I had to do (because I wanted a scenario of scrolling vertically, but also horizontally, and when the latter case, the old subviews had to be removed and new ones had to be created and added to the document view programatically). To manage the tracking areas of all the subviews that came and went or that were in a scrolling view in such a scenario is really a nightmare. I can understand that, because NSTrackingArea objects were not designed to handle such dynamic scenarios. Apparently, there are exceptions to this. I checked several example of sample code by Apple that NSTrackingArea objects can be used quite well even in a scrolling view as along as they are in an NSTableView or NSOutlineView (for that I highly recommend that you check the PhotoSearch and the HoverTableViewRow sample code).
2) Using NSTrackingArea with the option NSTrackingCursorUpdate and overriding cursorUpdate does not work well in small rects (e.g. heights around 7.0 or less).
3) I learned that you do not have to override -updateTrackingAreas for the NSTrackingArea objects to update in some scenarios. You can check this in the HoverTableViewRow sample code by Apple, which uses this method to set up the tracking area once without any further work from the developer, which goes against the sample code given by the documentation. I tried it in my code and it worked although it did not solve the bug I was hitting.
4) After experimenting many, many scenarios suggested by Ken, Quincey and John, I find out that that the only way to make everything work as I intended was to create a unique NSTrackingArea in the document view and then using mouse-moved events inside this rect to find the subview and then dispatch this event to it. This solved all my problems and now the tracking is correct even with the inertia scrolling on.
I hope this will help someone else in the future.
> On 17 Jul 2015, at 04:31, email@hidden wrote:
>
> Why not just observe bounds change notifications from the clipview?
> Then handle those with the update call.
>
> Sent from my iPhone
>
_______________________________________________
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