Re: The mouse is where?

FROM : Jayson Adams
DATE : Sat Jan 26 02:43:06 2008

On Jan 25, 2008, at 4:19 PM, <email_removed> wrote:

> Ah, thanks for pointing those out, Jayson. Now that you mention 
> them I do remember finding those in the past, way back in Tiger days.
>
> Unfortunately, you don't actually win the $64. Although 
> mouseLocationOutsideOfEventStream is *an* answer -- and an answer 
> is a lot better than no answer -- it isn't *the* answer, because 
> it's not synchronized with the event stream. Although it's where 
> the mouse is *now*, it's not where the mouse is "now", but rather 
> where the mouse "will be" when all the events currently queued have 
> been dispatched.


I wasn't trying to answer your main question, just the one about how 
do you figure out where the mouse is at any time.  But I also argue 
that the only thing that *ever* really matters is where the mouse is, 
as you say, *now*.  Unless I'm trying to store every spot the mouse 
has been, I don't ever want to operate on a queue of stale mouse 
locations.  If I'm dragging out a selection rect, for example, it's a 
bug if the corner of the selection rect is not always under the mouse.

> At risk of being long-winded, I'll add that there are 2 situations 
> where the distinction between now and "now" matters:
>
> -- When an application starts up. Depending where the mouse is 
> relative to the window that opens, something in that window might 
> get rollover highlighted inappropriately.
>
> -- When the first responder status changes to another view (such as 
> a text field) and then changes back again without involving the 
> mouse (such as tabbing back to the original view).


I didn't follow your examples.  In general, before you decide to 
highlight anything (e.g. in response to a mouseEntered: message) you 
can always check to see if the mouse is really within the tracking 
rect bounds.  If it isn't, don't highlight anything.

Best,


__jayson

Circus Ponies NoteBook - Organization for a Creative Mind
www.circusponies.com