Keyboard/Input focus: MS windows vs linux [message #85527] |
Wed, 14 August 2013 17:06  |
Paddy Leahy
Messages: 7 Registered: August 2013
|
Junior Member |
|
|
I've run into an incompatibility between windows and linux in the handling of focus events. Can anyone think of a workaround for the following?
I'm developing a widget application with a draw widget. To allow the user to use standard IDL direct graphics while the application is running, it swaps the graphics state, including colour tables and active window, every time it gains or loses keyboard focus.
The draw widget has motion events enabled. Just as one would wish, IDL generates these as soon as the cursor is positioned over the widget, even if the widget does not have focus. But this does mean that the event handler has to look out for this condition, swap the graphics state, and explicitly grab focus using:
WIDGET_CONTROL, widget_id, /INPUT_FOCUS
Under linux, if widget_id is the draw window, this generates a KBRD_FOCUS_EVENT with ENTER = 1 which reaches the top-level base event handler, and the system knows that the widget has gained focus, so when a different window is clicked it generates a KBRD_FOCUS_EVENT with ENTER = 0, cueing a graphics state swap.
But under MS windows, no KBRD_FOCUS_EVENT is generated (at least, none reaches the top-level handler) and the system still regards the focus as being elsewhere, so the graphics state is not swapped back when focus is transferred to another window.
On the other hand, if widget_id is the top-level base, windows does, but linux
does not, generate a KBRD_FOCUS_EVENT. Unfortunately, even then windows doesn't seem to recognise that the widget has focus (unless I click on it), so no ENTER = 0 event is generated when I click elsewhere.
I'm running IDL 7.0 under windows. The behaviour under linux is the same for IDL 7.0 and 8.2, and for different x-windows systems, so I think the key factor is unix vs microsoft.
|
|
|