A LabVIEW tool suggestion

[Yair]

Staying until the end of NIWeek has its advantages: At the end of the very last session in the last day, frequent LAVA poster Darren showed a demo of a potential time saving tool he was thinking about for a future LabVIEW version.

The tool allows you to use a simple key combo which will cause a small pop up to appear. You type the name (or keyword) of the function you want it use, it uses autocomplete and when you click enter you can immediately drop it in your code. This will allow you to drop any VI from the palettes in your code in a few key clicks without having to dig it out from the palette.

The problem is that I was impatient, so I wanted this now. So, while waiting for my flight the next day, I coded up a quick example (7.0) to see how it would work, and it is a very simple example - type the name of a function\VI in the string and press Enter. It will allow you to drop that function\control in the BD\FP of any VI.

There are some issues with it, however, and I want opinions.

1. Dropping the function is easy. There is a method for doing that from the palettes.
   
2. The hardest part is probably parsing the potential names. Different LV versions with different toolkits and modules installed will have different VIs. Also, the user.lib VIs are also part of this list.
   The most promising solution looks like the palette API, but it remains to be seen whether this can be backsaved to 7.x (which is what I want). Another problem is that parsing this will probably take time. I think that this will need to be a step which the users perform manually when they want to update the list by calling a specific VI which will do this.
   
3. Another problem is monitoring this. This can't be done using LV events. I was thinking of using polling and trying to load the tool at LV startup and having it run in the background all the time. I believe this is relatively simple using some callbacks which LV has, but I need to check if they work with 8.x. This could obviously interfere with what users do, but I think it's the only viable way.
   
4. The method used to do this ignores whether or not the VI with focus is in edit mode. It basically allows to drop in any VI which is in edit mode.
   
5. A nice addition would probably be using autocomplete in the middle of a word and using keywords to stand for VIs, but that would require a more complicated algorithm than this quick example.
   
6. At the moment, this is relatively similar to the search window. What would be its advantages over it?
   

What do people think about all this? Are there alternative suggestions?

[Ton Plomp]

QUOTE(yen @ Sep 1 2007, 10:25 PM)

The tool allows you to use a simple key combo which will cause a small pop up to appear. You type the name (or keyword) of the function you want it use, it uses autocomplete and when you click enter you can immediately drop it in your code. This will allow you to drop any VI from the palettes in your code in a few key clicks without having to dig it out from the palette.

....

3. Another problem is monitoring this. This can't be done using LV events. I was thinking of using polling and trying to load the tool at LV startup and having it run in the background all the time. I believe this is relatively simple using some callbacks which LV has, but I need to check if they work with 8.x. This could obviously interfere with what users do, but I think it's the only viable way.

...

6. At the moment, this is relatively similar to the search window. What would be its advantages over it?What do people think about all this? Are there alternative suggestions?

Yen you limit yourself way too much

What about the current discussions on using http://forums.lavag.org/index.php?showtopic=8739' target="_blank">custom shortcuts for tools options.

What about a 'Update SCC'/Check out/Run VI analyzer

A lot of things come to mind.

A probable event driven approach to 'key down' is added.

I've looked at your code but haven't studied it... (sorry)

Ton

[orko]

It would seem that you could avoid a lot of initial drawbacks to this idea if you made it a VI you place on the pallete window vs. a shortcut key activated thingy. Sure, a key to bring this (and many other VI's I could think of) would be nice, but I have a feeling that in future releases of LabVIEW they will allow custom VI's to be associated with shortcut keys (NI correct me if I'm wrong...but why else would there be that hint of a "bug" in the File menu shortcuts...?).

I would suggest that getting the autocomplete while typing feature and the "refreshing" of the VI lists would make this tool very beneficial by itself. Then perhaps we can get some kind of workaround so all of our nifty tools can be popped up with a keystroke.

Just my 2 cents

Great idea by the way!!!

[PJM_labview]

QUOTE(tcplomp @ Sep 1 2007, 02:05 PM)

...A probable event driven approach to 'key down' is added...

Ton

You can not register event on VI which are not running (this is a pitty really). Therefore the portable event driven approach VI you attached will not help in this situation.

PJM

[Yair]

You should note that the key is here is not opening the VI. That's relatively simple. The key is getting the list of all the VIs and primitives (and controls?) in the palettes. At the moment, I used the list from the New VI Object primitive in LV 7.0, but that is not a solution.

To demonstrate this tool more efficiently, here is a better version. As you can see, the polling is not that bad.

Instructions:

1. Run the VI. It should auto-hide.
   
2. From the BD of any other VI, press Shift+Q. That should open it (although it would actually open regardless of where you are. That's one of the problems with this).
   
3. Start typing the name of function until you get the one you want (e.g. TCP Close).
   
4. Press Enter to drop the function.
   
5. Repeat for as many functions as needed.
   

One issue is that when you first run it, it takes a few seconds before it allows you to drop the function, but I don't think that can be worked around.

As said, there are many improvements which could be made, but I don't want to do anything before I know I can enumerate the palettes. Can anyone with LV 8.0 try to backsave the palette API linked to in the first post?

[Yair]

Two new (related?) important points I thought about -

1. Will this work fine across 8.x application instances?
   
2. If the VI is running in the background, it means that when you close all your other VIs, the getting started window will not appear because there is still a VI in memory, so LabVIEW would just seem to disappear.
   One way around this is to run this process as a separate executable, but that requires opening VI server access and would cause troubles with multiple concurrent LV versions.
   Another way is to open and close the VI each time, but since we can't create a permanent menu shortcut, I don't see how to do that other than attempting to include the VI in the top level of the palettes, which would require a few mouse clicks.
   Does anyone have other suggestions or ways to make these usable?
   

[orko]

QUOTE(yen @ Sep 3 2007, 11:57 AM)

Another way is to open and close the VI each time, but since we can't create a permanent menu shortcut, I don't see how to do that other than attempting to include the VI in the top level of the palettes, which would require a few mouse clicks.

I personally wouldn't mind having it somewhere near the "Select a VI..." icon in the pallettes as opposed to making it a daemon. My mind would be in that zone anyway when I went to search for a VI ("I need a VI... click, okay, Find a VI...").

Just how my mind works. YMMV

[Darren]

QUOTE(yen @ Sep 3 2007, 01:57 PM)

Does anyone have other suggestions or ways to make these usable?

For my prototype at NI Week, I didn't need to do any polling. I'll give you a hint...I found a VI-based utility that you can launch from a keystroke in LabVIEW, and I hijacked it by putting my Quick Drop VI in place of the existing utility.

-D

[JDave]

QUOTE(Darren @ Sep 3 2007, 07:19 PM)

For my prototype at NI Week, I didn't need to do any polling. I'll give you a hint...I found a VI-based utility that you can launch from a keystroke in LabVIEW, and I hijacked it by putting my Quick Drop VI in place of the existing utility.

-D

Ooohh, hijacking existing tools to use their hotkeys. :ninja: Now that is a nice idea. Not for the mass markets, but if you just want your tool to have a hotkey...

[Michael Aivaliotis]

All of this is nice and fun but any solution proposed is still something that is a hack onto the LabVIEW IDE. It also will be a tool made by someone or some entity that thinks they know what I want. What I would really like to see is an API for the rest of us. Something that allows anyone to create extensions to the environment. Event driven, shortcut driven, context sensitive etc. Ya, I know, it takes time and costs money and NI has their priority list... I'm just saying.

Typing something into a textbox to get a function? Those icons on my pallete have names? Who would have thought. Now I just have to figure out what everything is called and I'm set.

[LAVA 1.0 Content]

What is it called?

Modulo? No. Quotient and Remainder.

Xor? No. Not Exclusive Or.

I'll stick with the icons... As long as we agree to leave the friggin' palettes alone!

[Michael Aivaliotis]

QUOTE(LV Punk @ Sep 4 2007, 11:24 AM)

I'll stick with the icons... As long as we agree to leave the friggin' palettes alone!

First rule of all LabVIEW releases. Palettes will change.

[bbean]

QUOTE(yen @ Sep 2 2007, 02:16 PM)

Can anyone with LV 8.0 try to backsave the palette API linked to in the first post?

Sorry Yen, Backsaving doesn't work.

[Yair]

QUOTE(Darren @ Sep 4 2007, 05:19 AM)

For my prototype at NI Week, I didn't need to do any polling. I'll give you a hint...I found a VI-based utility that you can launch from a keystroke in LabVIEW, and I hijacked it by putting my Quick Drop VI in place of the existing utility.

Unfortunately, I couldn't find any such tools in LV 7.0, but even if I could, it wouldn't be useful, since I don't want to hijack an existing tool.

Using some LV voodoo, I did make a successful attempt to intercept the not-really-used Ctrl+Q (instead of Shift+Q), but I can't get LV not to try to close the VI, so you get the close dialog after dropping the control. I might try to work on that angle a bit more.

Another method I tried was setting the VI to be a system VI, but that does not cause the main screen to open again when all other VIs are closed.

P.S. "Quick Drop". Hmm...

Nah... I like my "DropIt" ©® better. :laugh:

QUOTE(LV Punk @ Sep 4 2007, 09:24 PM)

What is it called?

Modulo?

No

.

Quotient and Remainder.

Xor?

No

. Not Exclusive Or.

One of the points I refered to earlier was that we could have aliases, so that you don't have to remember the exact name of the VI\Primitive.

QUOTE(bbean @ Sep 5 2007, 02:34 AM)

Sorry Yen, Backsaving doesn't work.

. Thank you.

OK, here's another idea - we could have the list modifiable for each user - if we attempt to drop a function and we fail, that function is moved to another list, so that it is not parsed anymore. That way, we can get a complete list from LV 8 and simply remove stuff from it. It will probably need to be more complicated than that, but that's the basic idea.

[JDave]

QUOTE(yen @ Sep 5 2007, 10:59 AM)

Unfortunately, I couldn't find any such tools in LV 7.0, but even if I could, it wouldn't be useful, since I don't want to hijack an existing tool.

Why not? If you can hijack a tool you don't use, then no problem. It is a hack, but as Michael mentioned earlier that is a problem that NI has to deal with. There are people who are trying to extend the IDE, and they really want some hooks to plug into. Capturing the hotkey in a background daemon is still a hack. But then maybe you use all the existing tools...

QUOTE(yen @ Sep 5 2007, 10:59 AM)

Using some

LV

voodoo, I did make a

successful

attempt to intercept the not-really-used Ctrl+Q (instead of Shift+Q), but I can't get

LV

not to try to close the VI, so you get the close dialog after dropping the control. I might try to work on that angle a bit more.

Is this voodoo a VI that constantly monitors for key strokes? If so, how would you deal with correct hotkey combinations, but at the wrong time -- i.e. when another application has focus? And why are you using an existing key combination (Ctrl+Q) ? LabVIEW will always capture this. You can change the menu shortcuts (is that LV 8+ ?) or you can choose a shortcut that isn't used, like Ctrl+Shift+Q.

[Yair]

QUOTE(dsaunders @ Sep 5 2007, 09:33 PM)

Why not? If you can hijack a tool you don't use, then no problem...But then maybe you use all the existing tools...

I may not use all the tools, but I was\am hoping to release this. As such I can't take any tool I feel like taking. In any case, since I did not find any such tools, I don't see that I can.

QUOTE

Is this

voodoo

a VI that constantly monitors for key strokes?

No, that was what I did in the demo I uploaded.

The voodoo is VI callbacks. You can get LV to run your VIs if you give them special names and connector pane patterns and put them in the LabVIEW x.x\resource\plugins folder. In this case, I believe I created a VI called lv_exit.vi which is called when you try to exit LabVIEW (e.g. by pressing Ctrl+Q). I can look up the documentation tomorrow if you want. My problem was that I couldn't get it to abort the exit sequence and it always tried to close the VI I was calling it from.

The problem with menu shortcuts (apparently) is that they don't stick. When you restart LabVIEW, you will lose them.

[JDave]

QUOTE(yen @ Sep 5 2007, 12:04 PM)

I may not use all the tools, but I was\am hoping to release this. As such I can't take any tool I feel like taking. In any case, since I did not find any such tools, I don't see that I can.

I understand. That was my sentiment when I mentioned earlier that this is not for mass markets.

QUOTE(yen @ Sep 5 2007, 12:04 PM)

No, that was what I did in the demo I uploaded.

The voodoo is VI callbacks. You can get

LV

to run your VIs if you give them special names and connector pane patterns and put them in the LabVIEW x.x\resource\plugins folder. In this case, I believe I created a VI called lv_exit.vi which is called when you try to exit LabVIEW (e.g. by pressing Ctrl+Q). I can look up the documentation tomorrow if you want. My problem was that I couldn't get it to abort the exit sequence and it always tried to close the VI I was calling it from.

The problem with menu shortcuts (apparently) is that they don't stick. When you restart LabVIEW, you will lose them.

If I understand correctly, aren't you still hijacking an existing item? The only VIs that can have shortcuts attached to them in that folder are items that are already in the menu, right? I must be missing something. What is different with overriding something in the resource\plugins folder instead of overriding something in the project folder?

[Yair]

QUOTE(dsaunders @ Sep 5 2007, 10:56 PM)

If I understand correctly, aren't you still hijacking an existing item?

The VIs don't exist (well, they didn't. 8.5 seems to have lv_new which intercepts Ctrl+N). You need to create them and you should be able to use them to filter the output. Theoretically, I could replace the lv_new VI with my own VI and only open the new dialog if the user clicks Ctrl+N twice, but I don't want that. Ctrl+Q is preferable, but I haven't been able to discard the exit event yet.

[Yair]

QUOTE(yen @ Sep 5 2007, 11:24 PM)

The VIs don't exist (well, they didn't. 8.5 seems to have lv_new which intercepts Ctrl+N).

Correction. lv_new_vi.vi is the one which intercepts Ctrl+N, and that does not exist in 8.5, so we're fine.

Attached is a version which uses this. Unzip the files into LabVIEW\resource\plugins.

Essentially, it works like this:

Click Ctrl+N and the dialog comes up. If you want an empty VI, click Ctrl+N again. If you want to drop something, type it and press Enter. I don't particularly like it, but I used it a few times during the day and it works, so I think I will stick with that. Two other improvements are that backspace works now and that you can tab to the next word.

The thing is that I now need a good algorithm for dealing with the lists and with filtering (preferably also stuff which is inside the string). I'm guessing that showing a listbox of the potential results and having the arrow keys automatically work on that list would probably work. The main problem is that now we need to load the entire list every time we open the VI, so I want to find a way to make this efficient. I would appreciate any suggestions\code anyone has.

As for the callbacks, I found http://openg.org/tiki/tiki-index.php?page=LvDocDevEnvEventCallbackVIs' target="_blank">this page, which is probably where I found out about it originally. It might be a good idea to transfer it to the LAVA wiki. (hint, hint).

[orko]

QUOTE(yen @ Sep 6 2007, 10:11 AM)

As for the callbacks, I found http://openg.org/tiki/tiki-index.php?page=LvDocDevEnvEventCallbackVIs' target="_blank">this page, which is probably where I found out about it originally. It might be a good idea to transfer it to the LAVA wiki. (hint, hint).

I've been using that as a reference as well, but unfortunately the ConPane images have disappeared!

Jim: Do you still have the images, and can we get a good copy into the wiki?

[Yair]

QUOTE(orko @ Sep 6 2007, 08:45 PM)

Jim: Do you still have the images, and can we get a good copy into the wiki?

I knew I had it somewhere.

[orko]

QUOTE(yen @ Sep 6 2007, 10:56 AM)

I knew I had it somewhere.

Much better! Thanks Yen!

[Val Brown]

QUOTE(dsaunders @ Sep 5 2007, 11:33 AM)

Why not? If you can hijack a tool you don't use, then no problem. It is a hack, but as Michael mentioned earlier that is a problem that NI has to deal with. There are people who are trying to extend the IDE, and they really want some hooks to plug into. Capturing the hotkey in a background daemon is still a hack. But then maybe you use all the existing tools...

That's precisely the problem IMO and one of the main reasons that, while I support open source efforts (esp things like OpenG!), I will NOT use the tools in any distro. I know that's probably a minority opinion (esp here!) but here are some of my reasons.

1. I pay for Platinum Support so I konw the ONE source I can ALWAYS go to and get, in the end, the Final Answer. Yes, I LOVE the support that we get here ---- [sounds of applause] -- but I don't count on it for distros. I want someone or some entity that is ultimately responsible and actionable if things go south.

2. I want one, single licensing environment so I don't have to worry about whether I've included BSD, BVDs or valentine's that acknowledge the latest Easter Eggs.

3 I want to be able to walk up to ANY system and simply BE ABLE TO USE IT. I do NOT want to know (and I especially don't want to HAVE TO KNOW) that on "this system" CNTL-Q closes an app but on "that system" it launches the missles, so don't forget to call Moscow as soon as possible.

I'm all for customizability but I do not want to have to rely on it for me to be able to do my work.

[JDave]

QUOTE(Val Brown @ Sep 6 2007, 01:48 PM)

QUOTE(dsaunders @ Sep 5 2007, 11:33 AM)

Why not? If you can hijack a tool you don't use, then no problem. It is a hack, but as Michael mentioned earlier that is a problem that NI has to deal with. There are people who are trying to extend the IDE, and they really want some hooks to plug into. Capturing the hotkey in a background daemon is still a hack. But then maybe you use all the existing tools...

That's precisely the problem IMO and one of the main reasons that, while I support open source efforts (esp things like OpenG!), I will NOT use the tools in any distro. I know that's probably a minority opinion (esp here!) but here are some of my reasons.

I am not sure what is precisely the problem. That it is a hack? Or that the extended IDE would be third party, and thus not something that NI will support?

QUOTE(Val Brown @ Sep 6 2007, 01:48 PM)

1. I pay for Platinum Support so I konw the ONE source I can ALWAYS go to and get, in the end, the Final Answer. Yes, I LOVE the support that we get here ---- [sounds of applause] -- but I don't count on it for distros. I want someone or some entity that is ultimately responsible and actionable if things go south.

2. I want one, single licensing environment so I don't have to worry about whether I've included BSD, BVDs or valentine's that acknowledge the latest Easter Eggs.

These are valid points that each programmer or organization must take into account.

QUOTE(Val Brown @ Sep 6 2007, 01:48 PM)

3 I want to be able to walk up to ANY system and simply BE ABLE TO USE IT. I do NOT want to know (and I especially don't want to HAVE TO KNOW) that on "this system" CNTL-Q closes an app but on "that system" it launches the missles, so don't forget to call Moscow as soon as possible.

I'm all for customizability but I do not want to have to rely on it for me to be able to do my work.

I completely agree that changing the way the LabVIEW IDE works from one system to the next is confusing and is a 'hack'. Extending the IDE is the decision of the developer to put additional functionality into the IDE -- that does not mess with the original behavior. Thus any developer would still be able to use it because all the base functionality is the same. So while I think it is cool that I can hijack a Tools menu item, it is also sad that I am breaking the IDE in order to extend it.

In the end, there are things I want to do in the IDE that aren't available. Where is the built-in Tunnel Wizard? Or something to color nested structures with alternating colors? Where is the ability to select multiple controls and hide the labels on all of them at once (or any other common property) ? I would love to see these available in the LabVIEW IDE. In order of preference, this would be possible by

1. NI incorporating additional IDE capability into future versions of LabVIEW. If they incorporate what I want, lucky me.
   
2. NI providing extensibility to the IDE so that third party groups (or myself) could implement what NI didn't.
   
3. Extending the IDE inspite of itself, aka hacking the IDE.
   

The third option is the worst, and it is what Darren did by hijacking a Tools menu item. It is what yen is doing by overriding the Ctrl+N callback. It is what I plan on doing for my own fun stuff. But this should not be migrated to other machines unless the new owner is fully aware of what is being done. Kind of like the Rusty Nails warning about scripting. Fun stuff, but beware.

So while #1 would be great, and it would allow NI to support everything, I think #2 is necessary. Then you could have a suite of OpenG IDE extensions that aren't incorporated into the distro, but would be used to facilitate coding up the distro.

[Val Brown]

QUOTE(dsaunders @ Sep 6 2007, 03:22 PM)

That's precisely the problem IMO and one of the main reasons that, while I support open source efforts (esp things like OpenG!), I will NOT use the tools in any distro. I know that's probably a minority opinion (esp here!) but here are some of my reasons.

I am not sure what is precisely the problem. That it is a hack? Or that the extended IDE would be third party, and thus not something that NI will support?

Yes, yes and yes. The issue fundamentally for me is support, esp in re: to the fundamental tool itself.

QUOTE(dsaunders @ Sep 6 2007, 03:22 PM)

These are valid points that each programmer or organization must take into account.

I completely agree that changing the way the LabVIEW IDE works from one system to the next is confusing and is a 'hack'. Extending the IDE is the decision of the developer to put additional functionality into the IDE -- that does not mess with the original behavior. Thus any developer would still be able to use it because all the base functionality is the same. So while I think it is cool that I can hijack a Tools menu item, it is also sad that I am breaking the IDE in order to extend it.

In the end, there are things I want to do in the IDE that aren't available...

So while #1 would be great, and it would allow NI to support everything, I think #2 is necessary. Then you could have a suite of OpenG IDE extensions that aren't incorporated into the distro, but would be used to facilitate coding up the distro.

Perhaps but again for me -- and it's probably a minority opinion -- I'm very hesitent to really use such things UNLESS they do come from and are supported by NI.

I know some folks swear by ADO for their DB interactions but I prefer to stick with NI's own DCT. Why? Because if/when there's a problem I KNOW where to go to get it resolve, or find out that what I want is impossible with the current tools/options/feature set supplied by NI.

I've simply had too many problems in the past with 3rd party "add on" gidgets, widgest, tools, etc -- esp obviously when DLLs are involved. I want to be as pure, simple and direct as possible and to know that, as far as possible, I can simply update to the latest NI release and have very little, if any, problems with my code.