Re: Key window/first responder handling with NSDrawer containing NSTextView
Re: Key window/first responder handling with NSDrawer containing NSTextView
- Subject: Re: Key window/first responder handling with NSDrawer containing NSTextView
- From: Luke Evans <email@hidden>
- Date: Mon, 4 May 2009 14:15:24 -0700
Further to this...
The workaround of subclassing NSTextView, and having a mouse down
event set push the first responder to itself, seems to work OK.
It's a rather annoying/plaltry reason to have to subclass however. I
still wonder if I'm looking at a bug, or some lack of education on my
part regarding how you would have the drawer window and its content
automatically take the first responder status when clicked
(particularly the NSTextView).
Perhaps someone has experience here and can comment on a better way to
get this working, without the subclassing.
-- Luke
On 4-May-09, at 12:57 PM, Luke Evans wrote:
I have an NSDrawer on a window that acts as an optional 'pop out'
editor providing a more convenient way to edit text in smaller field
in the window's main UI.
I've used the occasional drawer before in cases where optional extra
information/navigation is useful, and aside from one bug I know of
with drawers and GC, I figured having an NSTextView in one would be
a simple matter.
However...
The behaviour of key window management seems awry in my current,
straightforward UI (more or less just as composed in Interface
Builder). The first time the drawer is popped open and I click in
the text view, everything is fine, but if the I click back into some
UI in the main window (e.g. a table row), and then click again into
the drawer's text view to type some more text, the caret stays in
the text view, but key events are not routed to that view. Indeed,
the table row that I clicked on remains fully selected and as first
responder (highlighted blue rather than grey).
I can get the text view to take the first responder/key status again
by clicking on the background of the drawer (not all of the drawer
area is taken up with the text view) and have a click there assign
the that view's window as key. That seems to be all that is
necessary, but clearly I want the user to simply click back in the
text view to be able to continue to edit there.
Perhaps I could work around this by subclassing NSTextView and
implementing a mouseDown handler that simply attempts to set the key
window to the drawer window and/or first responder to the text view?
Any other ideas? It seems like I'm in some corner-case that demands
a work-around with some overt first-responder handing code, but
perhaps it's simpler than this and I'm just overlooking something.
-- Luke
_______________________________________________
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