On Jan 21, 2009, at 00:12, Luke Evans wrote:
I changed the scroll view cursor to pointingHandCursor and guess
what appears after the short pause? Pity cocoa doesn't have a
standard icon of a smoking gun :-)
No, but you got the Flying Fickle Finger of Fate, which is almost as
good.
Right, well at least now I know the perpetrator! The next question
is of course what to do about it.
I looked in the NSScrollView, NSClipView and NSView documentation,
and I think "poorly documented" is a bit mild. I can see the
methods on NSScrollView and NSClipView, but haven't found anything
that indicates when the scroll view updates the cursor, how to stop
it trying or how to know that it has gone and messed with the cursor
so I can 'repair the damage'. Any suggestions for the fix?
I can probably have my code update the scroll view's idea of what
the cursor should be every time I assert it - but that seems
extremely awkward. I tried setting 'nil' as the cursor to see if I
could bind the little imp in NSScroller and prevent him from setting
the cursor, but apparently he interprets this as my desire to have
an arrow cursor forced on my table view every few seconds.
I'm hoping for a reasonable way to turn this off - otherwise is
really seems like a bug (to harken back to by original subject line).
The only thing I can think of, offhand, that *might* have the timing
you describe is automatic toolbar item validation. Do you have a
toolbar on this window by any chance?
Or, if something in your underlying data model is changing constantly,
there may be a stream of user interface element updates causing this.
For example, if you're constantly telling the NSTableView that its
(variable) row heights are changing, it may keep resizing itself
without any actual updates being visually apparent.
If you're devious enough, you might be able to set a breakpoint where
NSScrollView is setting the cursor. (You could try, for example, to
subclass NSCursor using an image you supply, with an override of
setCursor: that just calls super. Then pass a cursor of your subclass
to setDocumentCursor.) The backtrace when the breakpoint is hit
*might* give you a clue as to why it's doing it.
If you want to try for a quick fix, I'd suggest you try turning on
mouseEntered/Exited for your tracking area, and to change the
NSScrollView cursor on mouseEntered, and restore it on mouseExited. It
wouldn't be perfect, due to some unrelated defects in tracking areas,
but it might well be good enough.
_______________________________________________
Cocoa-dev mailing list ([email protected])
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]
