On Jan 10, 2015, at 08:46 , ecir hana <ecir.h...@gmail.com> wrote: > > if I figure out something useful […]
Seems to me that this discussion has gone off the rails. Aside from a caveat that, of course, things may have changed slightly in Yosemite in ways that we haven’t noticed yet, NSTrackingArea isn’t that broken — though it can be a bit inscrutable. The wrong way to go about this is to start flailing about with floating windows and exploratory trips to Neptune. The right way to do it is to break the problem down in manageable pieces: — Make sure you *start* by investigating whether the tracking area options are configured correctly. You’re wasting your time if you go off looking for interactions between “sibling” tracking areas if in fact you just put the tracking area’s rect in the wrong place. — If you can’t get it to work with the button, try ignoring the button, and add a custom view as a sibling of the text view. If that works, then perhaps the button is doing something itself that’s interfering with your intentions. — Re-arrange your view hierarchy so that the button [or your custom view] is still a sibling of the text view, but does not overlap it at all. Install a tracking area that (say) changes the pointer to a pointing finger, so it’s really obvious when it works right. If it doesn’t, the problem is nothing to do with the text field. There’s no point in going on to the next step until this works. — Then, move the button so that it partially overlaps the text field. You should now be able to see if there are any side-effects of crossing into and out of the overlap. If there are, you’ll have to do extra work to find a solution. — Put your view hierarchy back to how it should look, and verify that everything still works. It’s been a while since I did anything with NSTrackingArea, but IIRC there is something slightly unusual about cursorUpdate:. IIRC it’s one or other of these things: a. The cursorUpdate: is sent to only one target, unlike the other tracking methods which are sent to all relevant tracking area owners. b. The cursorUpdate: is sent to the view to which the tracking area is attached, rather than the tracking area’s owner. Please note that I could easily be wrong about both of these, so don’t take them too seriously without additional testing. But if there is some kind of weirdness that’s specific to cursorUpdate, you may need to subclass NSButton in order to add your custom cursorUpdate: to it. Just don’t start down this road until you’re sure you need to. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
