Key window/first responder handling with NSDrawer containing NSTextView
Key window/first responder handling with NSDrawer containing NSTextView
- Subject: Key window/first responder handling with NSDrawer containing NSTextView
- From: Luke Evans <email@hidden>
- Date: Mon, 4 May 2009 12:57:00 -0700
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