Re: Keyboard navigation for a view
Re: Keyboard navigation for a view
- Subject: Re: Keyboard navigation for a view
- From: Daniel Jalkut <email@hidden>
- Date: Thu, 2 Feb 2006 18:34:56 -0500
Hi Robert - I haven't run across this (yet), but may I suggest you
play around with "bringing the host window into the game" by
dynamically hooking up the host window's first responder at nib-awake
time?
For instance, what happens if you do something like this:
[[self window] setInitialFirstResponder:oMyFirstTextBox];
From your AU's NSView awakeFromNib method?
It's been a while since I played around with the keyboard responder
chain, but I believe the "initial first responder" for a window gets
reused time and time again as the window itself is asked to be the
first responder. If it's not hooked up to anything, I think it kills
your chain.
I'm not sure if awakeFromNib is too late to revive it as designed in
IB, but maybe at the very least after resetting the initial first
responder you'll be able to successfully set everything else
programatically.
Good luck and let us know how it goes!
Daniel
On Feb 2, 2006, at 2:24 PM, Robert Abernathy wrote:
I'm building an Audio Unit that uses a Cocoa UI. The Audio Unit UI
is hosted as a view, not a window. The host provides the window.
I'm trying to set up keyboard navigation (tabbing). The IB
techniques fail completely. The Audio Unit reverts back to using
the system calculated loop when run.
I've tried to do the setNextKeyView route programmatically with the
same result.
Is it possible to set this up in a view that isn't associated with
a window? Am, I just being brain dead and this is really easy?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden