On Aug 25, 2010, at 1:30 AM, Quincey Morris wrote:
@implementation MyCustomDocumentView
- (void)windowDidBecomeKeyNotification:(NSNotification *)notification
{
if ([notification object] == [self window]) {
NSPoint point = [[self window]
mouseLocationOutsideOfEventStream];
NSRect frame = [self convertRectToBase:[self frame]];
BOOL condition = NSMouseInRect(point, frame, NO);
if (condition) {
[[NSCursor crosshairCursor] set]; // Called but does not
work!
}
}
}
@end
The implication of this is likely that the cursor is being set again
after you do it. Have you tried setting a breakpoint on [NSCursor
set]? It's tricky to debug, because you don't want application
switching to mess up the testing conditions, so you probably need to
enable the breakpoint from the floating debugger window, and/or use
carefully constructed debugger conditions.
I checked this with a breakpoint. When a window become key the cursor
is set. So setting a custom cursor using this approach will never
work. This also explains why setting the cursor in initWithFrame: or
awakeFromNib of a NSView object also will not work.
a. Unconditionally set the cursor to a crosshair when your document
window opens.
b. Set the cursor to a crosshair when your document window becomes
key while the mouse pointer is inside your view. (Or when it becomes
main? If there were a key window and a main window, would your
custom view be in the main or the key window?)
You're going to have to get (a) to work before (b) can work, and
you're going to have to get (b) to work before your tracking area is
going to work.
Apparently with Snow Leopard the cursor is now updated when the window
is made key. I think this is the functionality I was looking for. Mac
OS X Snow Leopard Release Notes on NSTrackingArea states "When setting
the cursor for the current mouse location, for example after scrolling
or when making a window key, NSWindow now sends cursorUpdate: through
the responder chain." Implementing something like this in Leopard
would take some thinking and time.
The best combination of options is probably 'NSTrackingCursorUpdate
| NSTrackingAssumeInside | NSTrackingInVisibleRect'. (Ignore the
documentation for NSTrackingAssumeInside -- it's wrong. The only
case when you *don't* want to use it is when your tracking area
behavior must not start until the mouse pointer makes a true outside-
to-inside transition after the tracking area is installed. That's
not the situation here. OTOH I'm not entirely sure whether the
option affects cursor update events at all.) Don't bother with
NSTrackingActiveWhenFirstResponder until after you've everything
else working, since it just adds complexity to the conditions.
I have taken your advice using NSTrackingAssumeInside but discarded
NSTrackingActiveWhenFirstResponder options for now.
Incidentally, the "approximately" above comes from the difficulty of
testing whether the mouse is inside the tracking area. ....
Thanks for the insight. Currently I am just getting started with
cursor management, which is why I was surprised when I immediately hit
a brick wall. I think I am off and running again now.
--Richard
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
