Re: GET_KBRD()... behavior depends on OS properties? [message #39410 is a reply to message #39277] |
Mon, 10 May 2004 14:07  |
MKatz843
Messages: 98 Registered: March 2002
|
Member |
|
|
I think you can solve your problem with a minor change in strategy.
Instead of using GET_KBRD() and simple graphic windows, go the extra
step and create a small widget containing a widget_draw(), and set the
keyword /KEYBOARD_EVENTS.
Here's what I do. I create a widget containing (at least) a text-input
widget_text() field that's small, along with a widget_draw(). You can
use object graphics or direct graphics as you're probably used to. The
user can click in the text field and enter keyboard commands.
Alternately, any key that is typed when the input focus is on the
graph window is identified and send to the same routine that deals
with input for the text-field.
In the event handler, I add one line that returns input focus to the
special text field after other appropriate events like mouse clicks in
the window and such.
Using this method I can handle a combination of keyboard commands and
multi-button mouse events all seemingly in the graphic window. It
makes a powerful, quick interface.
If you need more details, let us know. I probably got this technique
originally from suggestions posted on this newsgroup years ago.
M. Katz
> When I select the Click Mouse option, now I can get GET_KBRD() to work
> when my cursor is parked anywhere in the desktop (including the
> IDL-generated plot windows) since the focus is still on the IDL xterm.
>
> Is there any way to force this behavior from inside IDL? I'm guesing
> probably not, but I'm hoping someone knows more about this than I do.
|
|
|