On Thu, Jun 26, 2008 at 2:20 PM, Nathan Vander Wilt <[EMAIL PROTECTED]> wrote: > I have a view that displays and allows interaction with a lot (hundreds, > even thousands) of small items. I am having trouble nailing down a good > design for event handling, and just as I was ready to plead for help I see > some other NSTrackingArea discussion that perhaps sheds a little light, but > still inconclusive. > > It seems tidy to clear and reset all my tracking areas as the view gets > redrawn, but that leads to situations like where an item moves relative to > the mouse instead of vice versa, and since tracking areas can't be moved, > the mouseEntered->mouseExited transaction gets killed halfway through with > the old tracking area. > > My problem is that the displayed items can get updated (moved, deleted, > etc.) in situations like this: > 1. The user mouses over an item, its tracking area fires, and some status > text elsewhere gets set to reflect what's under the mouse. > 2. Before the mouse moves away from the item, the item moves and its > previous tracking area is deleted. So now I never get that mouse exited > event, even though the status text should be cleared. > > So it seems I need to do more bookwork myself, but I'm wondering which > direction others would recommend: > a) Set up a single tracking area for the whole view, and perform all my own > hit testing every time the mouse moves. > b) Keep the per-item tracking areas, but perform my own testing in the edge > cases when active (mouse has entered but not exited) tracking areas are > getting reset.
I vote for option A. Efficiency should not be a concern. Unless your hit testing is completely ridiculous, it will execute orders of magnitude faster than the user can move his mouse. I have an app which sets the cursor based on hit testing against a potentially large collection of NSBezierPaths and have never heard of any performance difficulties in hit testing. Drawing, yes, but not the cursor management (which is what I use it for). If you can currently use tracking areas then your areas ought to be plain rectangles, which are vastly faster than NSBezierPath to hit test against. Reinventing hit testing shouldn't be much of a concern either, especially if your areas really are rectangles. Testing whether a point is inside a rectangle is a one-liner using NSMouseInRect, and you can basically just stick a loop around that and be done. Done properly, you can factor the update-status-text code into a separate method, then call it every time the mouse moves or anything else changes. Just remember to take into account clipping if your view is scrollable, you don't want your status text changing because the user mouses over where something *would* be if it weren't off the edge of your view. Mike _______________________________________________ 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]
