On Jun 26, 2008, at 11:20, Nathan Vander Wilt wrote:
Even though it seems like I'd be reimplementing something Cocoa already offers, I'm leaning towards option A: I'm not sure if I'll be able to foresee all the edge cases, and I'd be reinventing half the hit testing code there anyway. Does it sound reasonable from a maintenance and performance perspective to handle the mouse on my own inside my view? It seems like the tracking Cocoa provides is designed for more static content, or am I just missing the intended "Option C" recipe for my scenario?
There's a subtlety (or there was, and I haven't retested this in 10.5.2 or 10.5.3) that makes tracking areas annoying if you have to keep recreating them.
When you create a tracking area there's no event to tell you where the mouse is relative to the tracking area. If you *don't* specify the [misleadingly-named] "assume inside" option, there's no mouseEntered event until the mouse enters the area (meaning that if it's inside when you create the area you have to move out and in before you see an event). If you *do* specify the "assume inside" option, there's no mouseEntered event until the mouse moves.
IOW, when you create a tracking area you have to the hit testing work manually -- if it matters to your application -- until at least the mouse moves. If you go that far, you may as well do the work all the time and make the tracking area static and view-sized as an aid to filtering out mouse movement that doesn't belong the view.
(That's a point of view, not a dogged assertion.) _______________________________________________ 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 [EMAIL PROTECTED]
