On Jan 27, 2008, at 11:46 PM, Quincey Morris wrote:
On Jan 27, 2008, at 17:41, Jayson Adams wrote:
The answer to whether or not the mouse is within the tracking rect
bounds is NSPointInRect([NSEvent mouseLocation], trackingRect)
(you have to convert the mouse location to your view coordinate
system, of course).
I'm wondering where this information came from.
-- Are you sure it's not NSMouseInRect([NSEvent mouseLocation],
trackingRect,flipped), or [view mouse: [NSEvent mouseLocation]
inRect: trackingRect] (with everything converted to the correct
coordinate system)?
I wrote what I meant to write.
-- Are you sure that the tracking area code doesn't allow for
nested subviews and/or tracking areas? Does it handle overlapping
sibling views and/or tracking areas in a predictable way? A single
rectangle test won't work in those situations. (I suppose every
tracking area might be handled independently, with mouseEntered and
mouseExited messages for all of the views under the mouse
simultaneously, but the documentation doesn't say this, I don't
think. It certainly can't work this way for the cursorUpdate part
of the tracking function, because it has to pick a single tracking
area to take charge of the cursor at any given moment. But if true,
then yes of course a single rectangle test would work.)
So check multiple rects then, if that's what you think you need to do.
Let me lay the example out a bit more specifically, and see if I
can change your mind.
Suppose (for simplicity) the mouse happens to be moving smoothly
along the 45-degree diagonal. So it starts at (0,0) and moves
through (50,50) and (100,100) and (200,200) and so on.
Suppose that the mouse-down is at (0,0), and the mouse-up is at
(200,200).
Now imagine the state of the application in the middle of the
dragging sequence, at a moment when it's still processing a mouse-
moved event whose location is (100,100).
It's entirely possible (see below for more about this) that while
this event is being processed in the body of your while loop,
there's *already* another event in the queue -- in particular, the
mouse-up at (200,200).
It's *also* entirely possible that at the same moment, while the
same mouse-moved (100,100) event is being processed, the mouse
itself is *already* (in real-time) at (300,300).
In these circumstances, would it be correct or incorrect to extend
to (300,300) a selection rect being dragged out?
Obviously incorrect, and this error would not occur with the code
snippet I provided.
Best,
__jayson
Circus Ponies NoteBook - Organization for a Creative Mind
www.circusponies.com
_______________________________________________
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
