Out-of-order enter/exit events
Out-of-order enter/exit events
- Subject: Out-of-order enter/exit events
- From: Ricky Sharp <email@hidden>
- Date: Tue, 15 Feb 2005 07:58:35 -0600
I have a need to roll my own help-tag solution. I'm using a singleton overlay window for the tag and I have the following API to show/hide it:
@interface HelpTagWindow : NSWindow
+ (void)showHelpTag;
+ (void)hideHelpTag;
@end
A private class method (sharedHelpTagWindow) is used to create/obtain the singleton. The implementation of the APIs above are simply:
+ (void)showHelpTag
{
NSLog (@"showHelpTag");
[[HelpTagWindow sharedHelpTagWindow] orderFront:self];
}
+ (void)hideHelpTag
{
NSLog (@"hideHelpTag");
[[HelpTagWindow sharedHelpTagWindow] orderOut:self];
}
For testing purposes, I created a simple Cocoa app and in its main window, placed several custom NSViews (MyHelpTagView). The views use addTrackingRect:... to set up a tracking rectangle for their bounds. The views are all at least 2 pixels apart from each other; some being as far apart as 20 pixels. The view's mouseEntered: calls showHelpTag and mouseExited: calls hideHelpTag.
Results...
If I move the cursor slowly, I get the proper sequence of events when entering/exiting the views. But, if the cursor moves quickly, the enter/exit events still fire, but can be out-of-order. This leads to the following situation where the bounds of view A and view B do not overlap.
mouse enters view A; help tag shown
mouse enters view B; help tag shown
mouse exits view A; help tag hidden
I know this problem has been raised on this list before, but I don't recall any solutions. As stated above, I've verified that none of my tracking rectangles overlap. The problem ultimately is dependent on just how fast the mouse moves around as I can get it to occur between two views even 20 (or more) pixels apart.
The problem also occurs whether or not the window that contains the trackable views receives mouse-moved events.
In the Carbon-version of my kiosk-type app, I relied upon mouseMoved carbon events and managed my own show/hide cursor and show/hide help tag logic. If tracking rects are this unreliable, I have a feeling I need to manage things myself with mouse moved events.
Another solution may be to have things be "one-sided". i.e. I do not call the hideHelpTag API from my view's mouseExited:. Basically mouseExited: becomes a NOP. Also, timers would be used to initially show and then hide the tag:
on mouse enter...
if help tag not showing, start timer that will show it after a certain delay
else update contents of help tag (since we are now potentially over a different view)
Whenever the tag is shown/updated, a timer is created/reset to serve as the "hide" timer. If that timer fires, it will hide the help tag.
How have others dealt with enter/exit events such that order of events is important? Have you had to resort to using mouse-moved events instead?
--
Rick Sharp
Instant Interactive(tm)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden