Does LabVIEW take over keyboard presses?

[jamespherman]

I'm using a C api in my LabVIEW application through a call-library-function-node. I'd like to be able to gather keypress info in one of the functions in the DLL, but it seems like LabVIEW is hijacking the values gathered by the C function from the keyboard. Any info on this? Thanks!

[charris]

James:

Would it be possible for you to give us a few more details about the application and its intent?

How are you trying to collect keypresses in your external code?

Does the C code receive keypresses correctly when run independently of LabVIEW?

[jamespherman]

If I define a function in the following way:

int myKeyGet(void) {

int key = 0;

do {

key = getchar();

}

while(key==0);

return key;

}

And make a VI with only a call library function node set-up to call that function & an indicator for the return value, it hangs.

I've tried similar simple functions using kbhit() & getch(), but to no avail.

[tbob]

It does seem as if Labview does take control of the keyboard and does not relinquish it to the DLL.  Instead of a DLL, can you compile your code into an executable, and then call it with System Exec?  Maybe this will cause LV to relinquish the keyboard.  Just a guess.

[Dennis_Knutson]

Is there a reason you don't want to monitor the keyboard in LabVIEW? Look at the Connectivity>Input Device Control palette.

[blawson]

IIRC, CLNs execute in the UI thread.  It seems to me that if you use a CLN to call something that also is trying to access the UI thread, they could deadlock (but I have never tried this).  Could that be the issue?

[waldemar.hersacher]

Another way to monitor the keyboard or mouse in LV is to use an event structure. There are events and filter events for keyboard and mouse.

All solutions are only monitoring keyboard and mouse events send to the application. They do not monitor events send to other applications. In this case youhave to use a Win32 key event handler.

[jamespherman]

Thanks for all the replies! I'll respond in order:

"Instead of a DLL, can you compile your code into an executable, and then call it with System Exec?"

Haven't tried this yet. The reason I'm using a DLL is that I'm using an API for an out-of-the-box device (an eye-position tracker), and I've written several functions that I need to access, so it would be kind of a pain to write code for multiple executables, but I can do this if it comes down to it.

"Is there a reason you don't want to monitor the keyboard in LabVIEW? Look at the Connectivity>Input Device Control palette."

"Another way to monitor the keyboard or mouse in LV is to use an event structure. There are events and filter events for keyboard and mouse."

Putting these two together since they have the same answer... Long story short, I can't, once the function I'm calling is triggered correctly, it's waiting for user-input on the keyboard and thus the input read by labview will go unnoticed (I tried this several different ways).

"IIRC, CLNs execute in the UI thread.  It seems to me that if you use a CLN to call something that also is trying to access the UI thread, they could deadlock (but I have never tried this).  Could that be the issue?"

I'm actually a novice C coder and self-taught labviewer, this sound super intriguing, EXPLAIN PLEASE!

Finally, I'd like to mention that I have made a small amount of progress on my own with this issue. I believe that I need to create a window using something like the function CreateWindowEx, part of the native windows user interface functions, because when one creates a window, one also makes a process to handle events like user-input. I suspect that whatever process is created by labview to handle user input in the VI is rightly in charge of handling key-presses (I also suspect that creating an executable might get around this as well since the exe might create a process to handle UI), so it's more like my DLL is actually the one trying to hijack the key-presses, not the other way around. If this is so, I should be able to simply create a dummy window (drawing it off screen so I can still see all my front-panel stuff in LabVIEW)  to handle the UI and then kill it when I'm done. I'm trying to do this at present, but my novice C coder status is making it a bit slow going. I was hoping some LabVIEW engineer or somebody else might have dealt with this type of issue in the past and could simply send me some code to make it all a moot point...

Again, thanks for all the replies and suggestions!

[waldemar.hersacher]

Then it would be a little bit more complicated. You can catch the input in the DLL function. This function must use a technic called Windows hook.

Try a google search with the words "windows keyboard handler hook".

This way you can see a keyboard press before it is routed to the application which in this case is LV.

[blawson]

so it turns out that Call Library Function can be set to "Run in UI Thread" or "Run in any thread", with the former as default.  This can potentially be a big performance hit, just like frequently/repeatedly calling property nodes is.  On the other hand, if the DLL is not threadsafe (ok to run reentrant, basically), then requiring the UI thread will require it to execute non-reentrantly.

there are a couple of mentions here and in the CLFN help about what to do if you built the DLL from LabVIEW.  Sounds like you aren't doing that.  Maybe switching the thread option could help, but I just threw it out there as a possibility.