LabVIEW
How do I get keyboard events when window is not active
Here's what I'm at right now:
I don't think it will get simpler that that!
If you have a working setup using the interception tool, it would be great if you could share it. Always good to have options.
Search LabVIEW like a graph!
@nanocyte wrote:
If I were going to go the "dll" route, I might go for hooking the driver with the interception tool. It just seems simpler and maybe more efficient.
With the interception tool, you need to make a wrapper\driver\API that converts 'the interception callback' to LabVIEW events. This on top of installing the required kernel driver (if I understand the tool correctly), which is quite an invasive thing to do. The Keyboard hook also needs to convert 'the callback' to LabVIEW events, but that's all that is needed. So nothing needs to be installed.
@nanocyte wrote:
I'm very interested though in how you might implement the DLL using LV. I would think you'd need like call backs and other stuff you can't normally do in LV.
Making a dll in LabVIEW is as easy as making an executable. Simply add a build specification for a dll. It's getting the setup right that is tricky. Once you have a proper callback function, you can (have to, AFAIK) use LoadLibraryA and GetProcAddress to get a pointer to the function. Use that pointer to tell the caller the callee's address.
You can of course check out my solution to see how I did this. This is already used in my previous code 'dump'.
That's basically it. Except for all the caveats! You'll get problems for sure, that's all part of the dll game. The problems are hard to predict... What happens when you abort your VI, instead of a proper stop, is one of the usual suspects.
Hi Wiebe,
Have you ever ended up publishing this anywhere?
Thanks.
wiebe@CARYA escreveu:
I'll post a decent soon (probably on GitHub). I want to prevent everyone spending time on it. It's going to be awesome if I can say so myself 😁.
+ Filter events option (from within in the event structure, discard only though).
+ Global\LabVIEW only option.
+ VKey translation.
+ Multiple registrations possible (when not filtering).
+ 32 bit and 64 bit LabVIEW (not 32 bit Windows, if that still exists).
+ Automatic unhooking if main VI stops.
+ All native LabVIEW code, incl. the dll.
+ Of course open source.
+ Tried it in 2013 32 bit; also works (after recompiling the LabVIEW dll).
Feel free to ping this thread if I forget to finish this. I might (tend to) go on to the next thing.
wiebe@CARYA wrote:
Here's what I'm at right now:
I don't think it will get simpler that that!
If you have a working setup using the interception tool, it would be great if you could share it. Always good to have options.
I don't think you'd need that tool.
Registering for events is the right idea but if you want to catch keyboard events outside of the LabVIEW Window, why not just use the Acquire Input data from the Initialize Keyboard VI and shoot that up to your Event Structure using a User Event?
I knew I had an example of this, but you'd use something like this with a MessageID and Data (variant) when you are pooling the keyboard for key presses then shoot the message and it's data up to your user event.
I'm sharing just a screen capture of this because this is a program that I cannot share the full code for. If you'd like an example, I can make a quick-n-dirty one.
@felipefoz wrote:
Hi Wiebe,
Have you ever ended up publishing this anywhere?
Thanks.
No, but it has my (split) attention now.
The big showstopper was (is) supporting both 32 bit and 64 bit LV. Back then I didn't have both installed, but now I have so hopefully I test the code more conveniently.
@Eric1977 wrote:
wiebe@CARYA wrote:
Here's what I'm at right now:
I don't think it will get simpler that that!
If you have a working setup using the interception tool, it would be great if you could share it. Always good to have options.
I don't think you'd need that tool.
Registering for events is the right idea but if you want to catch keyboard events outside of the LabVIEW Window, why not just use the Acquire Input data from the Initialize Keyboard VI and shoot that up to your Event Structure using a User Event?
Because Polling is evil.
What is the right polling speed? 50 ms? 1 ms? Is 1 ms fast enough? Faster polling means more wasted CPU...
+ you might miss events
+ you can't filter events
+ it doesn't scale up that easily
+ exactly what input device(s) will you be monitoring?
+ key combinations can be generated without an input device (not sure if my solution will catch those to be honest)
wiebe@CARYA wrote:
@Eric1977 wrote:
wiebe@CARYA wrote:
Here's what I'm at right now:
I don't think it will get simpler that that!
If you have a working setup using the interception tool, it would be great if you could share it. Always good to have options.
I don't think you'd need that tool.
Registering for events is the right idea but if you want to catch keyboard events outside of the LabVIEW Window, why not just use the Acquire Input data from the Initialize Keyboard VI and shoot that up to your Event Structure using a User Event?
Because Polling is evil.
What is the right polling speed? 50 ms? 1 ms? Is 1 ms fast enough? Faster polling means more wasted CPU...
+ you might miss events
+ you can't filter events
+ it doesn't scale up that easily
+ exactly what input device(s) will you be monitoring?
+ key combinations can be generated without an input device (not sure if my solution will catch those to be honest)
I agree that pooling is not the best solution but for what the OP wants, it may be his only option...plus I don't know how frequent his key presses are. If they are in rapid succession, then this approach won't work for the reasons you described, especially missed events.
@Eric1977 wrote:
wiebe@CARYA wrote:
@Eric1977 wrote:
wiebe@CARYA wrote:
Here's what I'm at right now:
I don't think it will get simpler that that!
If you have a working setup using the interception tool, it would be great if you could share it. Always good to have options.
I don't think you'd need that tool.
Registering for events is the right idea but if you want to catch keyboard events outside of the LabVIEW Window, why not just use the Acquire Input data from the Initialize Keyboard VI and shoot that up to your Event Structure using a User Event?
Because Polling is evil.
What is the right polling speed? 50 ms? 1 ms? Is 1 ms fast enough? Faster polling means more wasted CPU...
+ you might miss events
+ you can't filter events
+ it doesn't scale up that easily
+ exactly what input device(s) will you be monitoring?
+ key combinations can be generated without an input device (not sure if my solution will catch those to be honest)
I agree that pooling is not the best solution but for what the OP wants, it may be his only option...plus I don't know how frequent his key presses are. If they are in rapid succession, then this approach won't work for the reasons you described, especially missed events.
The OP explicitly mentions "I'd like to get keyboard events (key up, key down)"... 😁
Seriously though, the few times I had to use device input, for lack of an alternative, it wasn't nice to work with, didn't solve the problem entirely and was unreliable.
In fact, that experience made me work on an alternative. For the nth time, each time with increased determination. This time somewhat successfully (time will tell).
BTW. I (still) use device input to read out a joystick position. This is actually a very nice fit.
