LabVIEW Idea Exchange

I would be helpful if the Python nodes supported Python Virtual Environments. One of the powerful features of Python is able to setup multiple separate environments on a single computer, it would be LabVIEW's Python integration could also leverage this. TestStand already does have this capability, so hopefully it could be quickly/easily leveraged into LabVIEW. 😁

When I use an event structure, the case I use about 99% of the time is "Value Changed".  This is a bit of a pain since it is alphabetically at the bottom of the list, so I have to scroll down the list every time to select the event.

 

Since I suspect most people use this event the most, I would like it to be the default value when defining an event.  This way, I could just select the control and be on my way!

 

Bruce

Compared to plain terminals and references (for example), local and global variables are too big. They waste way too much space on a bulky frame.

 

In my applications, local variables often come in large groups (e.g. if I need to write values from a file to a group of controls inside a case to load a different default set for the controls) and I tend to partially overlap the locals to save diagram space. I would prefer a more economical design, e.g. as shown on the right.

 

Globals could have that little globe (not shown).

 

I am not sure if we really need to encode read vs. write in the frame thickness like for terminals, but it could easily be done by making the frame of the "write" versions thinner (same outer dimensions). I think the little triangle is enough to show the direction.

 

Just as for Clusters, I would like to be able to change a Map constant on the Block Diagram to be viewable as an Icon when it has been made a TypeDef.  You can't directly edit the constant data, so for me it doesn't make it worth the large amount of real estate that it can take up, especially if you have a Map of Maps/Sets.

So for example, instead of this:

I would like:

 

As mentioned here, "I lost count of the times where I have a cluster or enum constant that I want to make into a type def and have to first change it into a control, switch to the FP, and then select customize" - it'd be great to be able to right-click on a constand (like a cluster) on the block diagram and select Advanced -> Make Type Def (of course, you'd need to save the type def somewhere).

Even though I use the tools selection in the automatic mode, many times I need some specific tool not accessible in the automatic mode or force one like "Position/Size/Select". Sometimes, mostly designing User Interfaces (UI) that takes all screen, we got the Tools Palette blocking access to something. Then we move the Tools Palette until it get in front of something else.

 

The idea is to have an option to have all buttons in the toolbar. Some programs allows you "dock" just dragging the over the tool bar.

 

Many times we have plenty of space to have all buttons there, if not, we can have a second row of buttons. That will be nice to add more buttons as we wish.

 

 

PS: I added a swap button between the foreground and background colors. The idea is explained in this thread Swap Colors in Tools Palette.

This is related to this issue, https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Run-Code-Cleanup-profile-Nattify-VI-on-Save/idi-p/4291727

and is a more general request.

 

Have the ability to run custom scripting code on a save event.

 

What problem does it solve?

 

For me personally, I am working on an autoformatter. It would be nice to run that everytime something is saved. Right now I have to monitor the source folder from outside LabVIEW (using Python) and then use G-CLI to run my formatted. I'm sure there are probably other ways to do it and an onSave hook seems like the best choice. 

I'm sure there are plenty of other use cases. Perhaps some kind of linting or enforcing some sort of style guide. ie if you save a VI without a description, it won't let you unless you enter a description. Perhaps even every time you save a file, run some unit tests?

 

Ideal Solution

 

Ideally the scripting code would have access to the reference of the thing being saved. The easiest thing to envision is a VI, but why not also classes, libraries, the project itself? Maybe also some indication of what triggered the save. Was it a saveall, a save all this library, etc. Maybe if it is a saveall, you get a list of all the things being saved, before anything happens?

The IDE would then wait to continue until the scripting code completes, maybe even failing to save on an error or a boolean - not sure if that is the best behaviour as in a bug in your scripting code could cause you not to be able to save - so maybe some way to override the hook?

 

Maybe include a way to autogenerate a VI with the correct connector pane.

 

Maybe it makes sense to generalize this to add more hooks into LabVIEW? Perhaps a call to update the project provider to something more usable/less user-hostile?