Using windows thread and keyboard events

[Hpopenoe]

Does anyone know how to access the Windows 98 user interface thread or the
thread message queue that detects and/or holds keyboard events?

I am writing a vi that will detect certain keyboard events for my
application that has some data acquisition (time critical) and imaging
acquisition. This vi currently runs in the background of a while loop. The
vi uses the WINAPI call GetKeyboardState function in the user32.dll to
detect events. The problem is, a keyboard event is only detected when a
key hit is long enough or the timing of the event to reach that vi in code,
therefore mouseclicks might be lost.

The obvious solution seems to use multitasking techniques and have a
parallel operation just for detecting ev
ents. This seems to me wasteful of
processing time when windows does it already. Does anyone know how to use
window's messaging queue to set essentially an occurrence? and where to
find this documentation in MSDN? Perhaps there is a better solution.

I would appreciate any suggestions.

Thanks in advance.

Hugh Popenoe

[Bruce Kingsley]

Hugh:

Most likely the reason your not getting any keyboard information is because
Windows is dispatching keyboard/mouse messages to LabView's window first,
which results in LabView not needing the message and it's ignored. By the
time you call 'GetKeyboardState' the keyboard buffer has been purged.

I have written a C++ function in a my own DLL that traps keyboard messages
going to LabView. The problem with my function is it freezes LabView until a
key is pressed. Another problem with calling a message trapping function is
passing LabView's window handle to the API, so switching between windows may
result in the keyboard messages being dispatched to another application
running.

The best thing it seems would be to have a panel control that gets the
keyboard. This control would have to have focus to work.

Regards;

Bruce Kingsley


RBK Marble
* Software Design
* Electronic Design
* Home Theater Design
* Home Automation

WEB http://www.rbkmarble.com

EMAIL brucek@wolfenet.com




Hugh Popenoe wrote in message <39aaf513@newsgroups.ni.com>...
>Does anyone know how to access the Windows 98 user interface thread or the
>thread message queue that detects and/or holds keyboard events?
>
>I am writing a vi that will detect certain keyboard events for my
>application that has some data acquisition (time critical) and imaging
>acquisition. This vi currently runs in the background of a while loop.
The
>vi uses the WINAPI call GetKeyboardState function in the user32.dll to
>detect events. The problem is, a keyboard event is only detected when a
>key hit is long enough or the timing of the event to reach that vi in
code,
>therefore mouseclicks might be lost.
>
>The obvious solution seems to use multitasking techniques and have a
>parallel operation just for detecting events. This seems to me wasteful of
>processing time when windows does it already. Does anyone know how to use
>window's messaging queue to set essentially an occurrence? and where to
>find this documentation in MSDN? Perhaps there is a better solution.
>
>I would appreciate any suggestions.
>
>Thanks in advance.
>
>Hugh Popenoe
>
>
>
>

[Greg_McKaskle2]

> Most likely the reason your not getting any keyboard information is because
> Windows is dispatching keyboard/mouse messages to LabView's window first,
> which results in LabView not needing the message and it's ignored. By the
> time you call 'GetKeyboardState' the keyboard buffer has been purged.
>
> I have written a C++ function in a my own DLL that traps keyboard messages
> going to LabView. The problem with my function is it freezes LabView until a
> key is pressed. Another problem with calling a message trapping function is
> passing LabView's window handle to the API, so switching between windows may
> result in the keyboard messages being dispatched to another application
> running.
>

Perhaps I'm missing part of the problem description, but there
are
some keyboard VIs on the NI ftp site that give key character events
straight out of the LV event queue. They aren't the raw windows
events, but rather the platform independent ones that LV either will,
or has already processed, depending on how the VI registers.

The VIs are also probably available from the knowledgebase.

Greg McKaskle

[998800898]

Keyboard Events:

Is there a turorial on capturing keyboard events ?

The query device, and register user events vi's make no sense to me.

I need a vi that can either query a keypress from a buffer that is maintained by the active window.

Or an event that is triggered by a keypress.

This Vi should be called KeyPress event or something like that.

Why does the "Aquire Input data" Vi only allow me to select "Joystick" as the input device ?, this is useless.

[tst]

Perhaps you should try learning a bit about LV before going to use functions in the Advanced palette. If you actually read the help for the function (which is very easily accessible through a right click or ctrl+h) or look at the rest of the VIs in the palette, you can see that how the VI behaves depends on what you wire into it.

If you want to acquire key presses when your VI has focus you should use the event structure. If you want to get it at all times, you can use the Acquire Input Data VI to poll for the keyboard state (after you initialized a keyboard connection).

To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here and here are a couple you can start with and here are some tutorial videos. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf).

[Dennis_Knutson]

That's not a LabVIEW beginner. That's a LabVIEW professional programmer.

[tst]

---

@Dennis Knutson wrote:
That's not a LabVIEW beginner. That's a LabVIEW professional programmer.

---

Ah. Well, in that case, I take it all back. Someone who's so good in using LV that in 7 years they never found the need to use the help system must be highly professional. Someone who suggests recalling an application and sending a replacement older version instead of looking through the options menu is simply a genius - why bother spending money on new systems when you already have one which works very well?