Jump to content
Sign in to follow this  
Yair

A LabVIEW tool suggestion

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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 :D

Great idea by the way!!!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 ;)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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. ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

QUOTE(Darren @ Sep 4 2007, 05:19 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.

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.

Share this post


Link to post
Share on other sites

QUOTE(yen @ Sep 5 2007, 10:59 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...

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites

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

I knew I had it somewhere. :)

Much better! Thanks Yen!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

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.

Share this post


Link to post
Share on other sites

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

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.