On Apr 23, 2008, at 08:10, an0 wrote:
Chances are, calling '[[self enclosingScrollView]
setDocumentCursor:[NSCursor closedHandCursor]]' in 'mouseDown:'
will fix the
problem you're seeing. NSScrollView/NSClipView's way of changing
the cursor
conflicts with autoscrolling or drag-scrolling, but AFAIK there's
no way of
preventing that interference directly.
This partially works. However, if you move the item off the visible
part of scroll view and then move back, you'll find a arrowCursor
instead of openHandCursor when cursor hovers on the item. It seems
cursor problems pervade Cocoa applications and Apple just ignores
them:(
Does this sample application still use cursorRects/NSTrackingRects?
Leopard introduced a new mechanism -- NSTrackingArea and cursorUpdate
events -- which doesn't have some of the problems that the old
mechanism supposedly had.
With NSTrackingArea and cursorUpdate you should be able to get
complete, consistent control of the cursor inside the visible portion
of your view (even when returning from the outside), and it's fairly
easy to use. [NSScrollView setDocumentCursor:] will still be necessary
to control the part of the scroll view outside the visible portion of
your view, and control entirely outside the scroll view (or window)
will be harder to enforce, because other views (and other windows) may
have their own ideas.
_______________________________________________
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 [EMAIL PROTECTED]
