External Application Control Options (Hotkeys)

[Hooovahh]

Okay so I have some LabVIEW written code that works well.  I was trying to think of a neat way to be able to create global hotkeys which cause my software to do stuff from a key combination like CTRL+K.  In LabVIEW the best way to do this would be to be polling the keyboard constantly looking for key commands.  I'm not a big fan of this because I'll be polling a lot and if I add a delay, then I could miss key commands.

So my thought was to create another application, written in AutoIt or AutoHotKey, that just sits in the system tray and monitors for key combinations, then tells my LabVIEW program to do stuff.

If I go down this path I have a few options.  There is DDE, which is old and busted, and will requiring polling again on the LabVIEW side to see if a message came in, but at least I don't expect to miss any commands.

If I go with ActiveX I have a few other issues.  I can get the reference to the VI, and do something like set a control value, but I can't (or couldn't see) a way to set a control value with the Value Signal property node, I could just set the control.  Again here I'll need to be polling some hidden control to see if it was set, but still this is probably my favorite option.  Except there is one issue with this.  For this to work when I make my EXE I need to create the TLB file that gets registered by Windows so it knows what to do and what to call.  Up to this point I've been describing a single LabVIEW EXE, but in actuallity there will be about 6 or so EXEs, but only one gets ran.  So I'd need to make 6 different TLBs, one for each build, then my system tray hotkey program needs to call the right one based on which is running.

I could also go the cheap route and use File I/O.  Have my system tray program write to a text file, that my LabVIEW program looks for and does stuff if it exists.  I don't like the polling aspect, but I could look into a file watcher on a directory.

All of this sounds like a pain and no clear solution.  So the TLDR of the story is this:

What is the most reliable, and least system resource way to capture a keyboard shortcut in a LabVIEW application, that is not in focus?  If the answer is ActiveX, how can I handle the fact that there will be 6 mostly identical EXEs, and only one at random will be running at a time and connecting to that one?  BTW the OS is Windows but could be 32 or 64 bit, primarily Windows 7 but would prefer to have other OS support.

[Matthew_Kelton]

If you decide to go the ActiveX route, you can avoid polling by running a VI within the application instance.

Instead of just setting a control value, set an event, or add something to the queue.

I created a VI that is included in my EXE that added a command to the queue stack, but you could do the same thing with a user event.  The only reason I did this was to get the proper reference to the Queue (or Event) since it had to be in the name space.

I then create another handler VI that I built into a DLL that someone else's C code could call.  On init, it open an application reference to the main EXE, and then with that application reference, got a VI reference to the VI to pop a message into the queue.  After initialization, I just ran the VI in the EXE and passed the command into it.

[BowenM]

I'd be willing to bet this would work just fine:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms646309(v=vs.85).aspx

[Hooovahh]

Thanks for your suggestions guys.  The ActiveX run a VI to generate a user event sounds like a good enough solution, if I can get around the multiple EXEs issue.

I don't think the Windows Messageing thing would work for me.  I tried using that old toolkit floating around NI.com and couldn't register for the Null handle which I believe means desktop.  The toolkit at the moment gets the handle of that LabVIEW window and only responds when that window is active and you press a key.  As I mentioned I'd need it to activate on a global command.  Still if I played around with it this might be possible.

But I did some testing and polling the keyboard might just be good enough.  I made a separate while loop with a 100ms delay and it seemed to catch my relativly quick shortcut command.  I don't like it, but looking at all the other options they are a lot more work, adding various other dependencies, and other pitfalls to be aware of.  I may experiment with the file watcher method but that too adds other dependencies.

[Sam_Sharp]

I found a few useful links from this search - https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#safe=off&q=.NET+capture...

I was trying to see if there was a .NET class (e.g. this: http://www.codeproject.com/Articles/9351/Background-applications-listening-for-keyboard-act)for this but it looks like they all call into the Windows GetLastInputInfo function?

If you're writing your own little LabVIEW tray icon application to act as the hotkey listener - you could broadcast the hotkey events via UDP so that any application / application instance can listen?