Capturing keyboard events without window focus

[Chris Weiland]

I'm not sure why that design decision was made.  At least off the top of my
head, it would make more sense for wxGetKeyState() treat all keys the same,
and have another fuction, say wxGetToggleState(wxKeyCode key), that would
return the state of the toggle (on/off) rather than the physical key state
(up/down).

I won't be able to modify wx for each platform since right now I only have
access to a windows and linux desktop for development, but I might at least
be able to get those two platforms done sometime in the future.  I think for
now I'll just try to hack around the current implementation until I further
along in development.


I am currently calling wxGetKeyState() from my recording callback function,
and I admit that this is not the best way of handling it, especially if
wxGetKeyState is not a "lightweight" function.  The audio thread is seperate
from all other functionality, and is managed by the portaudio library.
However, I'm not sure what to do differently that would make much sense.

I could create another thread that sits in a tight infinite loop that
queries the transmit key then sleeps for a short time, but that still
wouldn't be calling wxGetKeyState from the main thread.  I don't like that
solution very much either.






On 6/2/07, Vadim Zeitlin <vadim at wxwidgets.org> wrote:
>
> On Sat, 2 Jun 2007 15:53:23 -0400 Chris Weiland <hobbiticus at gmail.com>
> wrote:
>
> CW> It seems as though I can query wxGetKeyState() for my transmit key in
> order
> CW> to accomplish this, but it doesn't quite get me there.  First of all,
> CW> wxGetKeyState does not handle toggle buttons like capslock in the same
> way
> CW> as other keys.  It returns true when capslock is on and false when
> capslock
> CW> is off, regardless if the actual key is pressed or not.
>
> Strangely enough this is done in wxGetKeyState() intentionally (just see
> its code). I'm not sure why it was decided to do it like this but it could
> be argued that the state of a toggle key is really the state it indicates
> and not its current pressed or not state. I guess we should either add a
> parameter to wxGetKeyState() telling it whether it should treat the toggle
> keys separately or add another function like wxIsKeyPressed() which
> wouldn't treat the toggle keys specially.
>
> CW> Second, if I call wxGetKeyState in my recording callback function
> CW> (which is the simplest, but perhaps not the best implementation), it
> CW> works just fine on windows.  But on linux, I get a line (once) on the
> CW> console that says: Xlib: unexpected async reply (sequence 0x948)! and
> CW> my program becomes unresponsive.
>
> Do you call wxGetKeyState() from another thread? If so, don't, it's a GUI
> function and so can be called only from the main thread.
>
> CW> So, is there another/better way of doing this within wxWidgets, or
> will I
> CW> have to find another (likely platform-dependent) solution to this?
>
> Currently there is nothing else but you could try to propose a patch to wx
> which would modify it to allow to do what you want. Like this you will be
> able to use this code in the next wx version.
>
> 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/20070602/197=
f8ba5/attachment.htm