Take a look at the attached app.
It opens 2 native OS windows, each containing 4 types of Pivot Windows (none of which contain any focusable Components).
It uses a simple mechanism to forward unhandled keyboard events to the active Pivot Window (if there is one)
Hopefully it demonstrates that you can target active Dialogs, Alerts & Frames without too much hassle.
I can see the value of building this kind of logic into Pivot's event handling, though. Anyone else have any thoughts on this?
1. Send the event to the focused Component if there is one
2. If not, send to the active Window if there is one <-- new step
3. If not, send to the UnprocessedKeyHandler if there is one
You might well be able to achieve something similar with a WindowClassListener too.
On 5 March 2011 14:36, Bill van Melle <firstname.lastname@example.org>
Sorry, that was my shorthand for "org.apache.pivot.wtk.Window opened on a Display object", thus corresponding in an obvious way to a window-system window. So you interpreted me correctly.
Yes, I think there is a 1:1 relationship between an OS WIndow and a Display. If the OS window has focus, but no Pivot Component inside of it has focus, the Application.UnprocessedKeyHandler will get the key presses.
which, of course, being in Application, is far removed from the window being opened by some random other part of the program. Of course, if the UnprocessedKeyHandler passed along the Display on which the key was pressed, it might still be usable (albeit clumsy) for what I want, but it doesn't. Which also means that, unless UnprocessedKeyHandler only gets called on the app's "main" display (and not for *every* Display as you suggest), I don't see how one could ever use it in a multi-OSWindow application.