Capturing keyboard events without window focus

[Chris Weiland]

Very good point about breaking existing code.

If i'm supposed to call wxGetKeyState from the main thread, where do I do
this?  Is there an "OnIdle" function that I can hook into?  If so, how often
is it called?  I'd like to get the state of the transmit key in as close to
real time as possible.

By the way, while I have your attention, I'm having another problem that I
can't seem to solve looking at the docs and you could probably answer pretty
easily.  I want to have a "bind key" dialog for choosing which button to set
as the transmit key, which is just a dialog with some text that closes
itself at the first keypress.  However, just making an EVT_KEY_DOWN (and/or
EVT_CHAR) event handler on my bind key dialog (inherited from wxDialog) does
not give me any key down events.  As suggested by the docs, I can override
ProcessEvent, but I only get all non-character key events (shift/ctrl/tab,
NOT a/b/c/etc).  I used the ProcessEvent found in the richtext example as a
template.  How do I get all events?

Also on the subject of keys, is there an easy way to translate a key code to
a human-readable string describing what key it is?  For example, when the
user binds the shift key to transmit, I don't want to display that they have
the key "306" bound.  I couldn't find anything in the docs, but maybe I'm
not looking in the right place.


Thanks for all the help so far.




On 6/3/07, Vadim Zeitlin <vadim at wxwidgets.org> wrote:
>
> On Sat, 2 Jun 2007 20:50:38 -0400 Chris Weiland <hobbiticus at gmail.com>
> wrote:
>
> CW> I'm not sure why that design decision was made.  At least off the top
> of my
> CW> head, it would make more sense for wxGetKeyState() treat all keys the
> same,
> CW> and have another fuction, say wxGetToggleState(wxKeyCode key), that
> would
> CW> return the state of the toggle (on/off) rather than the physical key
> state
> CW> (up/down).
>
> Yes, I agree that this would make sense. But this would silently break the
> existing code relying on the current behaviour and there is really no
> excuse for doing this as this behaviour is documented and so we should
> preserve it. This is why I think we need a new wxIsKeyPressed function.
>
> CW> I won't be able to modify wx for each platform since right now I only
> have
> CW> access to a windows and linux desktop for development,
>
> Implementing the new function for MSW and Unix would be a good start.
>
> CW> I am currently calling wxGetKeyState() from my recording callback
> function,
> CW> and I admit that this is not the best way of handling it, especially
> if
> CW> wxGetKeyState is not a "lightweight" function.  The audio thread is
> seperate
> CW> from all other functionality, and is managed by the portaudio library.
> CW> However, I'm not sure what to do differently that would make much
> sense.
>
> You must call wxGetKeyState from the main thread and set a flag (or signal
> a condition) which the audio thread would check periodically (or wait on).
>
> Regards,
> VZ
>
> --
> TT-Solutions: wxWidgets consultancy and technical support
>                http://www.tt-solutions.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-users-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wx-users-help at lists.wxwidgets.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wxwidgets.org/pipermail/wx-users/attachments/20070603/f2c=
b0b1b/attachment.htm