Re: NSPopUpButton subclass + Tracking Rects don't generate enter/exit events
Re: NSPopUpButton subclass + Tracking Rects don't generate enter/exit events
- Subject: Re: NSPopUpButton subclass + Tracking Rects don't generate enter/exit events
- From: Quincey Morris <email@hidden>
- Date: Sat, 16 Feb 2008 10:13:42 -0800
On Feb 16, 2008, at 02:01, Ben Lachman wrote:
Here is my pertaining code:
- (void)viewDidMoveToWindow {
// set up our tracking rect
frameTrackingRectTag = [self addTrackingRect:[self frame]
owner:self userData:nil assumeInside:NSMouseInRect([self
convertPoint:[[self window] mouseLocationOutsideOfEventStream]
fromView:nil],[self frame],[self isFlipped])];
NSLog(@"frame tracking rect: %@, frameTrackingTag: %d (inside:
%@)", NSStringFromRect([self frame]), frameTrackingRectTag,
NSMouseInRect([self convertPoint:[[self window]
mouseLocationOutsideOfEventStream] fromView:nil],[self frame],[self
isFlipped]) ? @"YES" : @"NO" );
}
Don't you mean [self bounds] instead of [self frame]?
- (void)setFrame:(NSRect)frame {
[super setFrame:frame];
[self removeTrackingRect:frameTrackingRectTag];
frameTrackingRectTag = [self addTrackingRect:frame owner:self
userData:nil assumeInside:NSMouseInRect([self convertPoint:[[self
window] mouseLocationOutsideOfEventStream] fromView:nil],[self
frame],[self isFlipped])];
}
And setBounds instead of setFrame.
But it's not generally correct to assume that setFrame is the only way
the frame can get changed, or that setBounds is the only way the
bounds can get changed (although it may be safe enough for the bounds
if you've set your button not to autoresize). The safe way to monitor
bounds (or frame) changes is to turn on bounds (or frame)
notifications for the view, register to receive bounds (or frame)
change notifications, and do whatever you need to do in the
notification method.
One more thing. Be careful about what 'assumeInside' means. The
behavior of the option was "fixed" in Leopard, which implies there was
something wrong with it in 10.4, though I don't know what the problem
was.
_______________________________________________
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