| Re: Ctrl-C keyboard event missing [message #34420] |
Tue, 18 March 2003 09:14  |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Tue, 18 Mar 2003 07:23:12 -0700, Mark Servetus wrote:
> I'm using IDL 5.6 and have used KEYBOARD_EVENTS at both 1 and 2 on my
> WIDGET_DRAW. I can catch all control key combinations except for Ctrl-c.
> That appears to not even create an event.
>
> Anyone know why this is or how I may be able to capture the Ctrl-c?
>
> Any opinions on 5.6 keyboard handling compared to the various clever
> workarounds?
You can get C-c with the "clever workaround" you mention (the ugly
WIDGET_TEXT hack I can't believe still exists), but probably not in a
platform independent way. Here's what I've used before with my hack
to trap control key combos directly:
if ev.ch ge 1b AND ev.ch le 26b then str='C-'+string(ev.ch+96b) else $
str=string(ev.ch)
E.g., you'd have "C-c" for Control-C.
Had KEYBOARD_EVENTS been written as a WIDGET_BASE functionality, such
that you could catch events no matter where in the application they
occur (except in input forms), it would have made a big difference.
As it exists on WIDGET_DRAW, you still need to set focus explicitly to
the draw widget, if you hope to catch key events while "outside" your
draw widget. Key statement from the manual: "The method by which a
widget receives the keyboard focus is dependent on the window manager
in use."
The nice thing about the WIDGET_DRAW key-event support is it's
presumably platform independent, and it can dish out keyboard events
at a much higher rate (e.g. for holding down the arrow key). Also, in
principle, you could hide a very small WIDGET_DRAW behind other
elements of a drawless widget-app, in the same way you hide a
widget_text with the original hack.
JD
|
|
|
|
| Re: Ctrl-C keyboard event missing [message #34481 is a reply to message #34420] |
Thu, 20 March 2003 04:47  |
markservetus
Messages: 7
Registered: November 2002
|
Junior Member |
|
|
It looks like I'll stick with the WIDGET_DRAW keyboard events, since I
would like the speed and platform independence. I'm using object
graphics with just one draw widget. The niceness of a Ctrl-c to which
I respond by placing the scene into the clipboard is hard to give up.
> Key statement from the manual: "The method by which a
> widget receives the keyboard focus is dependent on the window manager
> in use."
I do find it hard to believe that of all the keyboard combinations,
the window manager is withholding the Ctrl-c (if it is the window
manager and not some other IDL glitch that is blocking it).
Of course, it could be a bug on my platform, Win XP. Hmm... And maybe
it's just when running from IDLDE. Any more information out there?
Mark
JD Smith <jdsmith@as.arizona.edu> wrote in message news:<pan.2003.03.18.17.14.18.437273.31090@as.arizona.edu>...
> Had KEYBOARD_EVENTS been written as a WIDGET_BASE functionality, such
> that you could catch events no matter where in the application they
> occur (except in input forms), it would have made a big difference.
> As it exists on WIDGET_DRAW, you still need to set focus explicitly to
> the draw widget, if you hope to catch key events while "outside" your
> draw widget. Key statement from the manual: "The method by which a
> widget receives the keyboard focus is dependent on the window manager
> in use."
>
> The nice thing about the WIDGET_DRAW key-event support is it's
> presumably platform independent, and it can dish out keyboard events
> at a much higher rate (e.g. for holding down the arrow key). Also, in
> principle, you could hide a very small WIDGET_DRAW behind other
> elements of a drawless widget-app, in the same way you hide a
> widget_text with the original hack.
>
> JD
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
