Re: NSScrollView and NSTrackingArea woes
Re: NSScrollView and NSTrackingArea woes
- Subject: Re: NSScrollView and NSTrackingArea woes
- From: João Varela <email@hidden>
- Date: Fri, 17 Jul 2015 02:19:57 +0100
> On 15 Jul 2015, at 18:28, Quincey Morris <email@hidden> wrote:
>
> On Jul 15, 2015, at 03:08 , João Varela <email@hidden <mailto:email@hidden>> wrote:
>>
>> However, none of this happens when the user only scrolls (up or down) a little and does not reach the top or bottom of the document view. In this case, not only the -updateTrackingAreas method of the subview is not called, but also the cursor is no longer updated properly, because the NSTrackingArea’s of the subviews have not updated correctly. It seems as though I am not the only one getting bitten by this problem. See here:
>
> Your assumption about *when* updateTrackingAreas will be called is incorrect. Depending on the way you create the tracking area, and the amount of the scroll, the tracking area might not need to be changed at all.
It must be changed because when that happens the tracking area remains in the old location, which no longer coincides with the new location of the subview.
>
> So, there are at least three issues you need to resolve:
>
> 1. Are you setting up the tracking area properly? For example, are you specifying the area in the correct coordinate system? Are you using suitable options?
Yes, AFAICT. The options I am using are the following:
NSTrackingAreaOptions options = NSTrackingMouseEnteredAndExited | NSTrackingMouseMoved|
NSTrackingActiveInActiveApp;
I tried many other combinations, including NSTrackingActiveAlways instead of NSTrackingActiveInActiveApp
but that does not matter. The results are always the same. And yes, I am using the subview’s coordinate system, not the superview’s. I’m passing [self bounds]. And no, I am not using NSTrackingInVisibleRect
>
> 2. When you scroll the view, what *actually* happens to the tracking area? For this, you’re not interested so much in what happens immediately to the cursor, but rather whether moving the cursor away and back again will “find” the tracking area, either in the correct place or in an incorrect place.
See above. The tracking area does not follow the subview to its new location. However, as soon as the scrolling hits the top or the bottom of the document view they suddenly match again, because -updateTrackingAreas was called. If I use my hack of invoking the superview and subviews -updateTrackingAreas myself, it seems that this messes up the tracking areas, although with the following detail: It seems as though that the tracking area has been updated correctly, because if I hover the mouse on one of the scrolled subviews the cursor initially changes to the correct shape in the expected (correct) location, but almost immediately returns to the arrow cursor and stays like this as though all tracking areas were no longer there. Very weird. So I cannot use this hack. Another interesting thing is that Muthu’s suggestion about disabling inertia scrolling eliminates this problem completely, but it is an unacceptable solution, because the scrolling is not smooth any longer. So this bug has something to do with the inertia scrolling indeed.
>
> 3. The clip view (the view between the scroll view and the document view in the hierarchy) also has a tracking area, and the scroll view also has a “documentCursor” property. Thus, other views may explicitly change the cursor at unexpected times. You need to investigate whether the tracking area is incorrect, or whether the cursor is just getting re-set to something else.
Yes, the tracking area is incorrect and apparently I cannot invoke -updateTrackingAreas myself because it apparently messes up with the NSTrackingArea’s of the subviews and most likely of the clipView, etc.
So I guess this problem could be solved if there were a method to tell the OS that the tracking areas are invalid (and thus they need to be updated). However, apparently there is none, AFAICT. Or is there?
Another option, which I truly dislike, is to roll out my own tracking of the mouse in the document view by adding the tracking areas to this view instead of to the subviews, but then I would have to calculate the location of each subview, which is a waste, because that would come for free if I did that directly in the subview.
>
> Unfortunately, this is hard to debug, because debugging changes the state of your window and the position of the cursor.
You bet. I’ve been stuck with this apparently simple problem for a few days already.
_______________________________________________
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