| GET_KBRD()... behavior depends on OS properties? [message #39277] |
Sun, 09 May 2004 22:53  |
timrobishaw
Messages: 16
Registered: June 2003
|
Junior Member |
|
|
Hi there,
I've got a question I've been wanting an answer to for a long time.
Somebody named Phil asked this about 5 years ago here, but the thread
devolved into complaining about IDLDE rather than answering the poor
guy's question... so this post has nothing to do with IDLDE.
I use the CURSOR command a lot when investigating data... usually
spectra and images. Once in a while I try to get clever like so: if I
press a specific key (the output is returned via GET_KBRD(0)) then a
related task is run. But I'd really like GET_KBRD() to work while
the cursor is sitting in the spectrum or the image window... this way,
my routines can use the (x,y) position that the cursor is sitting at.
My big problem is that GET_KBRD() won't work until I get that cursor
back into the IDL xterm (thus changing the cursor position).
I'm running IDL on Solaris. Checking the desktop properties, I find
there's an option to control window focus (I think that's the official
name for this click-on-the-window-to-activate-it business):
Set Active Window: {Click Mouse | Move Pointer}
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.
-Tim.
|
|
|
|
| Re: GET_KBRD()... behavior depends on OS properties? [message #39407 is a reply to message #39277] |
Mon, 10 May 2004 22:56  |
timrobishaw
Messages: 16
Registered: June 2003
|
Junior Member |
|
|
Thanks a bunch guys! I'll give this WIDGET_DRAW() a try. -Tim.
> 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.
|
|
|
|
| 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.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
