Hi Michael,
thanks for your response.
>Now, this special key-processing caveat aside, key events will get delivered to your plugin view if the window that your view is in has focus. In this case, key events are sent to the >first responder of that window. If your view is not the first responder of the window, you will not get any key events.
>How does your view become first responder? Any textfields that are in your AudioUnit view will automatically respond correctly.
Here's the thing: Seen from an OS point-of-view, there's no text fields in my plug-ins. I'm working with a cross-platform API, and all text fields are "internal controls" (I hope that makes sense).
What I mean is, I have a window, which receives mouse events (and hopefully keyboard events soon :-)), and passes the events on to the internal controls.
So, I'm guessing 1 of 2 solutions would be best:
A: I can somehow receive keyboard events to my window (this is what I tried, and obviously failed in doing)
or
B: I can make an invisible control which covers the whole plug-in window.
But... in those cases, I need to be able to decide whether a key event should also be send to the host, or if it should "stop" with me. Why? Because otherwise I risk interfering with the shortcuts of the host.
Thanks again,
Michael Olsen
PhonoXone
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.
|