Re: NSTextView unselects on tab clicks...
Re: NSTextView unselects on tab clicks...
- Subject: Re: NSTextView unselects on tab clicks...
- From: jgo <email@hidden>
- Date: Sun, 8 Jul 2001 13:34:17 -0700
>
Brian Webster <email@hidden> Tue, 2001-07-03 15:27:42 -0500
>
> On Tuesday, 2001 July 3 at 14:35 jgo wrote:
>
> And what if it's set up like this
>
> +-----------------------+ +-----+ +-------+ +------+
>
> | | | \/ \/ \------+
>
> | | | |
>
> | NSTextView | | tab view |
>
> | | | |
>
> +-----------------------+ +---------------------------------
>
>
>
> You have some text selected in the text view and want what you do in
>
> the various tab views to apply to what you have selected. Which tab
>
> view you have shouldn't have any affect on what/whether you have text
>
> selected in the text view...
>
>
I was playing around with this in IB and noticed something
>
interesting. I had a text view set up next to a tab view that
>
has a text field in it. I made a selection in the text view,
>
and then clicked in the text field. The selection disappeared
>
in the text view and the cursor appeared in the text field. If
>
I click in the text view, then it just places the cursor where I
>
clicked, but if I hit the tab key, it switches the text view to
>
be the first responder and highlights the previous selection.
>
So apparently, the text view does maintain its selection range
>
internally, it just doesn't display it visibly when it's not the
>
first responder.
>
>
The problem seems to be that clicking on a tab in a tab view
>
takes first responder status away from the text view and gives
>
it to the tab view. You can tell that the tab view is the first
>
responder since you can then press the arrow keys to switch
>
tabs.
Hmm, well, my reaction is, of course when you click in another
view of any kind it becomes the "first responder". That should
have nothing to do with abandoning the existing "current
selection" in another view, or in causing it to be redefined
when you click in it... ahhh, except that's one of the
differences, isn't it. In 9- the first click in a different
window merely activated that app (if necessary) and made that
window frontmost (oh, 2 results, already) without, in general,
taking the click for any other purpose. And I agree that
there are many times when needing to do a second click,
e.g. on a button that was visible all along (or just this
minute when trying to select a resize box & having it take
3 clicks to get it to work), can be annoying
>
Note to Apple: there should really be some sort of visual
>
indication of this state. You could try subclassing NSTabView
>
and overriding -acceptsFirstResponder to return NO.
But I do want the tab to be the first responder when that
happens. It's hierarchy is the proper one.
This is an interesting situation. Would there be a way
to grab that view activation click to prevent it from
changing the current selection... but only such a view
activating click? I'll have to take a look.
John G. Otto Nisus Software, Engineering
www.infoclick.com www.mathhelp.com www.nisus.com software4usa.com
EasyAlarms PowerSleuth NisusEMail NisusWriter MailKeeper QUED/M
Will program Macs for food.