On Fri, Mar 4, 2011 at 12:47 AM, Chris Bartlett <[email protected]>wrote: > > > Perhaps I don't understand your exact needs, but I think this is exactly > what the Application.UnprocessedKeyHandler is there for. If the Pivot > app/applet has focus (is this what you are describing as the 'top-level' > window?), key presses will be directed to the focused Component if there is > one, or otherwise to the Application.UnprocessedKeyHandler if it has been > implemented. >
That being at the app level, it would work for the original window, but not for any others I might open. And as you note, the required redundancy with the window's ComponentKeyListener to handle cases where a child did have focus would be annoying. Would the above approach meet your requirements? If not, please explain in > more detail the structure of your GUI and the behaviour that you would like > to see so that we can think about how to achieve it. > I create additional top-level windows for things (usually dialogs of some sort) that are larger than Sheets are appropriate for (and that's not very large in an app where I let the user reshape the original window pretty much arbitrarily). My immediate need for a key handler there is to allow Escape to cancel the window. But I could imagine wanting other keyboard shortcuts, such as something to navigate among tabs in a TabPane (an unsolved problem you note). I was initially hopeful when you mentioned that a Display can have a key listener, since that's a sensible place to put top-level window key listeners. There is a one-to-one mapping from Displays to OS-level windows, right? Seems to me that the focused OS window should always be able to detect keys, and if no child component has focus, it should still be possible for the Display's key listener to run. Or am I misunderstanding something?
