| Re: Keyboard/Input focus: MS windows vs linux [message #85528 is a reply to message #85527] |
Wed, 14 August 2013 18:13   |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paddy Leahy writes:
>
> 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.
I'd say you were probably hosed. But, this seems a little clunky to
mean, and I'd do this another way. I'd store the graphics state in the
user value of the draw widget. Then, at the time you make the draw
widget the current graphics window to draw into it, restore it's graphic
state. That way it is always ready to go when you want to use it.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
