On Sat, Jan 10, 2015 at 4:54 PM, Uli Kusterer <[email protected]>
wrote:
>
> I think you’re reading that into the documentation. In most views,
> cursor-setting is pretty much predictable, and I think text views are
> mainly meant as an example here, and aren’t that special.
>
Yeah, you are probably right...
I did the same, and one thing that looks like it turns off the cursor is
> overriding resetCursorRects and updateTrackingAreas to do nothing, and doing
>
> -(void) viewDidMoveToWindow
> {
> [super viewDidMoveToWindow];
>
> [self.enclosingScrollView setDocumentCursor: nil];
> [self.enclosingScrollView updateTrackingAreas];
> [self.enclosingScrollView resetCursorRects];
> }
>
> That turns off the text view’s cursor, it seems.
Well, I have the custom textview which has empty both "resetCursorRects"
and "updateTrackingAreas", and the snippet from you above, and it still
sets the I-beam cursor. What's more, now it sometimes does not set the
cursor back to the arrow one when I leave the textview area.
I will definitely let you know, if I figure out something useful... One
idea is that I may just drop this "floating above" approach and do what
NSTextFinder does, namely temporary resize the enclosing scrollview and put
that button over the newly cleaned up area. I would prefer the former,
though, so I will try a bit more.
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
