Capturing keyboard events without window focus

[Vadim Zeitlin]

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/