What is the need to break a VI when a local variable in read mode is unconnected?

[X.]

What's wrong with an unconnected "read" local variable?

A control terminal (or indicator terminal for that matter) can exist on the BD without issues!

Use case: When I create a new control, I may want to drop a few local variables in different cases of an event structure to be connected later.

If in addition, I am planning to create a few controls, to be used in several cases, this is quicker than dealing with each case one at a time.

I'll just grab the terminal, create a local variable for it, copy it and then paste it in all the cases I need it in.

Then repeat with another control and finally, deal with the bunch of local variables in each case later on.

I would like to be able to run the VI without having to treat all cases, which I can't right nowm because the VI is broken as long as there remains at least one unconnected "read" local variable.

Again, I cannot fathom why the compiler would be unhappy with a "read" local variable unconnected to anything. Generate a copy of the data if you wish, don't use it, that's all!

I can see the problem with a "write" local variable, although I would wish an unconnected "write" local variable would be simply ignored. And probably the same should be done with an unconnected local variable: no copy should be generated.

Of course, a warning would be useful.

[tst]

Then put it on the IE (assuming it's not already there) and see how it fares. Personally, I think I prefer the current situation for safety (i.e don't forget to use the code you actually put in), but I wouldn't be terribly broken up if it behaved like you want.

[X.]

IE? I am drawing a blank...

[RavensFan]

Idea Exchange.

I never use that abbreviation myself because when I see IE, I think of Internet Explorer.