LabVIEW Idea Exchange

Is it possible to have a feature to quickly identify *.vi's and *.ctl's that are in the project tree but not used in your code anywhere?  Maybe the VI name could have a different color for the text or some other indictor for unused code?  This could also be a configurable option - you could have the ability to turn the highlightin on/off.

When you have a Format Into String node and you try to replace it with a Format Into File node (with right-click -> replace), LabVIEW doesn't reconnect all the inputs in a logical way.

Start off with this:

then replace it with Format Into File and you get:

.

The new node should be automatically expanded to the original size, and the inputs should be automatically connected. Obviously the "Resulting String" indicator would be broken because the output for Format Into File is a refnum (new idea: give Format into File an optional string output for easy previewing). The result of the replace should look like so:

Then we'd only have to fix two wires, not n+2.

I was reading this idea (Inline "Space constant.vi"), and I initially misread the title as "in-line space constant." This got me thinking... what if we could concatenate string constants on-wire? Give string constants an input which, if wired, concatenates the constant with the input. If it's not wired, it acts as a standard constant.

Since a picture is worth, well, a lot more words than I'm willing to type, here's what I'm thinking:

(the current method can also use Format Into String nodes)

Most of the time, Format Into String is my VI of choice for essentially any string building, but once in a blue moon I'm looking to do something like the above. So it's a pretty limited use Idea. But someone might like it, so I figured I'd post it.

What does everyone think?

Hello,

Sometimes, you have event structures which have to handle a big list of events.

With such a big list of events it's sometime hard to find the event you want to modify.

So, it should be nice to have the ability to Group the events by function, by keyword ....

In place of having a simple list, a 2 level treeView will be more user friendly.

Manu.

Most of the time when I want an error control I find a terminal, right-click, create indicator/control etc and in future will probably use the block diagram error constant .

However, at other times, I want to start from scratch with a blank vi and need to navigate the palettes.

It always annoys me that if I am working on a front panel and want to place an error-in control, I then have to repeat the action to put down a corresponding error-out indicator (or ctrl-drag, right click, change to indicator). It is pretty rare that I would want one without the other!

I propose the option to put both down at once, for example, by ctrl-clicking the palettes to make a multiple selection (i.e. similar to 'normal' windows based selection behaviour).

(I was going to suggest making ctrl-clicking for multiple selections standard across the palettes, but I can't think of any other sensible occasions where it would be useful)

To set 5 menu item infos, we have to set one by one, or using an array passing through a for loop...

Why not passing directly an array to this function ?

When I diff a VI, I am usually interested in the change in semantics or syntax, not the cosmetics. I usually don't care about moved wires and tunnels and stuff like that.

The critical word in here is "usually". Because there are cases when I might be interested in these changes, too.

We all know the command-line options like "-nobdcosm" and "-nofppos". But these require closing LV-Compare and restarting it. And they assume my RCS-frontend allows me to specify multiple command-lines for diffing the same filetype, which is not true for the one I use (TortoiseSVN).

So I would like to have a way of toggeling these (and the other command-line options) from within the LV-Compare window. Create checkboxes or fold them into a context-menu, there are many ways of implementing, either one will do.

Of course the user would have to update the list of differences after toggeling one of these options, but hey: the "Update" button is already there 🙂

 This would be a method on a VI that puts all properties for all controls and decorations back where they were when the panel was saved including moving positions, sizing, making visible controls visible and hiding invisible ones, etc. as well as sizing and scrolling the panel to its saved origin. There's "Revert VI", but I don't want to unload the VI -- the VI might be running when I want to call this method. Indeed, most often I would want the VI to call this method on itself. This is a method that needs to work in the runtime engine.

The goal is to be able to restore an interface to some known starting position before allowing various plugins/3rd party VIs to modify it, and to be able to repeat that cycle. Since it is impossible to know all the things that those third party VIs might change, a single "reload the panel from disk" method would help a lot.

Hello,

The "Check if file or folder exists" VI returns "TRUE" if you wire an empty path as input.

According to me, the VI should return false for an empty path.

I think this behavior is very dangerous !

An empty path is interpreted by Labview (Or Windows directly) as the main root C:\.

So the empty path always exists ... but ... is it really what the user wants ?

I think that this default empty value should be replaced by the root directory.

Manu.