@Chris
Quote:
Surely you will still be making the active window inactive momentarily, no matter how you are pushed the input events through?
Also this isn't only about KeyShow, but user expectations, and - ultimately - keyboard navigation.
Okay this subject off inot several directions here.
1. The virtual keyboad concept.
If you use an input handler / commodity approach, then window will be a visual guide only and will not directly handle input, because we need to intercept input before intuition ever sees it to be as much like a real keyboard as possible.
You would
a: Intercept (left) mouse down and mouse up events
b: Determine if they are over your window.
c: If so, check position relative to your virtual keyboard elements , determine equivelant raw key event and add it to the input stream then 'swallow' ie delete the mouse event. Activate any qualifier status needed.
d: If not pass mouse button event on as normal.
If correctly setup the virtual keyboard window never becomes active, so the focus issue is irrelavant.
2. General behaviour of windows, ie should the active gadget be remembered between deactivating and reactivateing a window. Possibly it should be an new option, enforcing it on exitsing apps could cause unforseen issues. Testing may find this is rare in which case the default might be to on.
3. Toobar windows an other applications.
If I'm working with app A and click on app Bs Toolbar, unless some care is taken the result may be a bit undetermined, no style guide covers this case.
Probably App B should come active in some what taking the focus from the App A, but that would require an intervention by App B (the one who owns the toolbar) to make it's main window active (or perhaps uniconify it it or what ever is appropriate).