Re: Command-Key modified cursor
Re: Command-Key modified cursor
- Subject: Re: Command-Key modified cursor
- From: Allen Smith <email@hidden>
- Date: Mon, 7 Jan 2008 15:09:05 -0800
On Jan 7, 2008, at 11:55 AM, John Nairn wrote:
On Jan 7, 2008, at 8:41 AM, Benjamin Stiglitz wrote:
I implemented tracking rects and used mouseMove to change the
cursor depending on modifier keys. In this case holding command
key is zoom in while command and option is zoom out. It works
OK, but pressing the command key does not get the correct curser
until the mouse physically moves again. I tried to find an event
for key press, but could not find one (command key or option key
alone do not generate keyDown event). I didn't try cursor rects,
but found no indication that cursor tracking would update
correctly on command or option key presses.
Check out -[NSResponder flagsChanged:].
-Ben
Thanks Ben,
That handles most of the issue, but since flagsChanged only
responds to changes, I had to handle special cases where the zoom
cursor should change even when the modifier flags have not changed
(e.g., when mouse enters or exits the zoom region, when the window
becomes or loses key, and also after doing a zoom (because that
redisplay also reset the cursor)).
One remaining issue is when window becomes key after losing key
status. I need to reset the cursor using the current state of the
modifier flags. I was hoping to find an NSEvent class method for
those flags (e.g. [NSEvent currentModifierFlags]) that would
provide the same function as [NSEvent mouseLocation], which returns
the mouse location at any time (i.e., not needing an event to
occur), but could not find one? Maybe a carbon call could work here?
Cursor rects should handle all the issues you described, including
mousing in and out of the view and the key window problem. The trick
for me was to update my cursor rects even when my view is not key;
that way, when the user clicks on the window the correct cursor is
waiting for him. I accomplished this by overriding -[NSApplication
sendEvent:] and tracking the current modifier state there, posting
notifications to interested views as needed. The high-level event
interception was doubly necessary because I am modifying the cursor
based on command-[nonmodifier key]. AppKit ordinarily swallows such
events as part of the menu key-equivalent dispatching.
The only hitch was unconditionally resetting the cursor rects. I
found that calling -invalidateCursorRectsForView: only reset the
cursor if there was already a cursor rect in effect. The following
hack forces the system to update the cursor no matter what.
[self addCursorRect:[self visibleRect] cursor:[NSCursor arrowCursor]];
[[self window] invalidateCursorRectsForView:self];
Note that Leopard introduced NSTrackingArea, which appears infinitely
superior to the old tracking rects. It may fix the issue I describe
above.
Allen
_______________________________________________
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