On Feb 4, 2009, at 14:55, Luke Evans wrote:
Calling my own -updateTrackingAreas when I know the autoscroll has occurred does not help at all - I can see the rectangles being constructed with the correct locations, but the view still sends events as if the scroll offsets within the clipView were the same as when the drag started.
This really does sound like a coordinate system issue after all. It may be a bug, or it may be correct but surprising behavior, or it may be a gray area of expectation. It seems worth a bug report to try to find out.
Is it "when the drag started", or is it when autoscroll last scrolled the view?
The situation when in a mouse dragging loop is much more serious though. The eventing concerning tracking area boundaries is totally unreliable, seeing as the view seems to be stuck with the tracking states as they were when the drag started. The mouse dragged messages arrive reliably, and one can perform _immediate_ hit testing on objects for which the tracking areas were intended, but now my view has to know to ignore the dodgy mouseEntered/Exited events which entails having some 'in drag' state distastefully pushed into the view object from the drag loop. Oh well.
Or perhaps there's a slightly cleaner workaround: regenerate your tracking areas at every autoscroll, using whatever offset you find to be necessary to get the tracking areas to behave as if they're in the right place. At mouseUp, regenerate the tracking areas one more time without the fudge factor, if you did the fudgy thing during scrolling.
_______________________________________________ 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
