| 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
