LabVIEW Hotkeys Alpha

[whitenoiz]

Introducing LabVIEW-Hotkeys

As there's nothing in this world that couldn't be improved, I've teamed up with a Windows Scripting specialist and we came up with a nifty tool that will give you Quickdrop as well as context-menus at your fingertips - for real - by assigning them to respective letters on the keyboard like CTRL-e will be simply e.

To give it a try, you can download it here along with a LV16 Demo-VI (I've also attached one for LV8 to this post) that'll show you around. Unpack the .zip and open the VI first to get instructions. Please always use a Virus-Scanner before using executables you've downloaded from the web.

As I'm aware of one or another quirk we haven't yet ironed out, questions and suggestions for improvements are welcome anytime.

Greetings
Markus

[Hooovahh]

Very interesting.  It doesn't always work well in my setup but interesting.

So the first thing I notice is this doesn't work well with non-auto tool.  If I tab to my text tool, then single click on the block diagram, and start typing, as soon as I hit "e" it goes to the front panel.

I turned on auto-tool double clicked started typing, then pressed enter and it did untoggle, but it also left a return in my comment.  Also it is pretty often that I will make a comment and want a new line in it.  For this I guess I'd need to turn off the auto toggle.

Manually toggling with F12 worked fine but I didn't like the untoggle, so I changed that setting.  Otherwise I would type a comment then the next comment would be toggled back on.

I am a fan of the icon in the system try changing based on the state.

I don't have QuickDrop setup as CTRL+Space.  I reserve this to move the active window to the next monitor.  This allows me to move windows around easier and I've had this shortcut since before QD so I remap QD to CTRL+D.  This apparently breaks somethings.  Like when I select the error constant and type "r" it moves the window to the next monitor (I'm guessing invoking CTRL+Space) and then runs the VI (I assume invoking CTRL+R).  Similarly and issue when I hit "r" to remove the unbundle by name.

Also I'm not sure how okay people are with running a random EXE off the internet.  I had faith (and a VM) and don't mind testing it without the source but others might be concerned.

Still pretty cool, but I don't think I'll be using it.

[whitenoiz]

---

So the first thing I notice is this doesn't work well with non-auto tool.

 You're right. For working around eight years with LabVIEW myself, I've found it hard to imagine you could get into any kind of a decent workflow without auto tool, albeit it does get fiddly at times.

If I tab to my text tool, then single click on the block diagram, and start typing, as soon as I hit "e" it goes to the front panel.

So yes, you've found that major flaw we're facing in advancing this way of working with LabVIEW. We currently don't have real LabVIEW context, as to what tool is active and what connector or element the user is clicking. Ideas anyone!?

I turned on auto-tool double clicked started typing, then pressed enter and it did untoggle, but it also left a return in my comment.  Also it is pretty often that I will make a comment and want a new line in it. For this I guess I'd need to turn off the auto toggle.

Same here, no context and the untoggle on <Enter> is actually just a guess. For my part, when teaching LabVIEW to newbies, "End text entry with Enter key" is the first option I recommend to set in LabVIEW settings as it also confuses everyone when working with strings. Most decently applications I know do allow for multiline editing by using CTRL-Enter.

I don't have QuickDrop setup as CTRL+Space. I reserve this to move the active window to the next monitor.

Well the good news is, that in Windows 10 you have combinations of WIN+Cursor to move one window around one monitor and WIN+Shift+Cursor to move it directly to your other screen.

Also I'm not sure how okay people are with running a random EXE off the internet.  I had faith (and a VM) and don't mind testing it without the source but others might be concerned.

Well, yes . As far as I'm concerned, I'd love to find out if I can take this further, like with LV-Scripting and that's why I decided to keep it closed source for now. You're free to convince me otherwise however! 😉

Thanks for taking it for a spin and writing that short review!

[Hooovahh]

First I'd say sorry if my reply sounded too negative.  I re-read it and should have highlighted a few more of the positives in producing something for free and giving it to the community.  Still I'll mention the community would love to have the source too.

I've been using LabVIEW for 14 years, back when auto tool was first suggested and people resisted it.  If you came into LabVIEW after it was on by default and accepted, you generally just use it and get used to it.  But since I can tab with one hand while moving the mouse with the other, I don't need to wait for my tool to change to what I want, and I don't need to click the exact right spot.  That being said NXG is auto-tool only and so I have thing to get used to.

The only thing I can think of to get the context of the current tool is to get an image of the mouse cursor, and using that determine what tool is selected.  This will likely have issues with the mouse moving to other windows, which change the cursor, and now the selected tool is again unknown.  I think using this technique it could be made better, but wouldn't cover all of the use cases.

I'm aware of Win+Shift+Arrow will move my monitor, but it is awful hard to hit that key combination with my right hand on my mouse.  CTRL+Space on the other hand is pretty easy.  To improve your tool you can simply read the LabVIEW.ini file and look to see what key combination invokes the QuickDrop window and use that instead of the hard coded CTRL+Space.

---

@whitenoiz wrote:

---

Well, yes . As far as I'm concerned, I'd love to find out if I can take this further, like with LV-Scripting and that's why I decided to keep it closed source for now. You're free to convince me otherwise however! 😉

---

This confuses me.  You say you want other to take this further, and potentially use scripting, but then you say that is your reasoning for keeping it closed.  If you really want people to use this, and take it further it should be made open.  I don't expect to be using this, but if this were written in LabVIEW and the source was made open, I'd might be interested in tweaking it to try to work better for my uses.

[whitenoiz]

---

This confuses me.  You say you want other to take this further, and potentially use scripting, but then you say that is your reasoning for keeping it closed.  If you really want people to use this, and take it further it should be made open.  I don't expect to be using this, but if this were written in LabVIEW and the source was made open, I'd might be interested in tweaking it to try to work better for my uses.

---

Just a quick reply to clear up your confusion: The tool is not written in LV at all, hence my eagerness to not give away the source right away.

[Barukh_t]

Very impressive, seems like a great tool.

Works much better Than QD plugin i was using for creating controls/indicators.

Don't get what it has to do with red pitaya though ( as written on the documentation for the vi).

[Barukh_t]

 One thing that would be great to have is the ability to add indicator on a wire, not just on a terminal - 

Press a wire and press ICreates indicator

[whitenoiz]

Thanks! Glad you like it!

I must've derived the example VI from one of the VIs of the RedPitaya LabVIEW driver which I also helped create a couple years back. Never did polish that corner, obviously, so thanks for pointing it out!