Re: Refresh View After Mouse Inactivity
Re: Refresh View After Mouse Inactivity
- Subject: Re: Refresh View After Mouse Inactivity
- From: Quincey Morris <email@hidden>
- Date: Sat, 30 Apr 2016 16:39:34 -0700
- Feedback-id: 167118m:167118agrif8a:167118sCJyTeT55u:SMTPCORP
On Apr 30, 2016, at 16:08 , Richard Charles <email@hidden> wrote:
>
> - (void)mouseInactive
> {
> // This does not work.
> [self setNeedsDisplay:YES];
>
> // This does not work. I think this did work at one time but stopped
> // working on OS X 10.10 Yosemite.
> [self performSelector:@selector(setNeedsDisplay:)
> withObject:@YES afterDelay:0.0];
> }
>
> - (void)mouseMoved:(NSEvent *)event
> {
> [NSObject cancelPreviousPerformRequestsWithTarget:self];
> [self performSelector:@selector(mouseInactive)
> withObject:nil afterDelay:2.0];
> }
>
> The problem is that calling setNeedsDisplay: does not work. It appears that the run loop is stopped. Once the user does something like press a key on the keyboard then the view is refreshed.
Do you have any proof that ‘mouseMoved’ is called at all?
Note that there are two different ‘mouseMoved’s. One is a continuous stream of events that come from via the window if “acceptsMouseMovedEvents” is YES. (It’s NO by default, and it’s a pretty bad idea to set it to YES, unless you enjoy avalanches.) The other is a stream of events that come from moving the mouse inside a NSTrackingArea, provided that the right initial conditions for detecting that the mouse is inside are satisfied. It’s not clear which technique you’re using here.
The other thing that occurs to me is that, following a recent discussion here about performSelector, you can’t validly pass @YES (an object) as a parameter to a method that expects a scalar value (a BOOL in this case). You’d need to wrap this in your own method that takes a NSNumber parameter, except that you’ve already sort of done that by providing this ‘mouseInactive’ method. (However, @YES would almost certainly produce a result of YES if mis-interpreted as a BOOL scalar, so that’s likely not the cause.)
Lastly, it’s always possible that something to do with power management is preventing events from being sent from the run loop. This is hard to figure out, because trying to debug it changes the scenario.
_______________________________________________
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