Re: Cursor above siblings
Re: Cursor above siblings
- Subject: Re: Cursor above siblings
- From: ecir hana <email@hidden>
- Date: Sat, 10 Jan 2015 17:46:46 +0100
On Sat, Jan 10, 2015 at 4:54 PM, Uli Kusterer <email@hidden>
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@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