Allow wiring to determine autoindexing

[Darin.K]

I am not lucky enough to have all of my While Loop tunnels be Last Value and For Loop tunnels to be autoindexing.  I seem to spend a lot of time undoing some favors that LV thinks it is doing for me.  I would like to be able to determine at wiring time the behavior of a tunnel, and I propose the following:

Tunnels created by dragging a wire across a loop boundary (For or While) should be Last Value.  I view it as 'I dragged from Point A to Point B, there should be no change in data type.'

Tunnels created by tacking a wire to the loop boundary should be autoindexing.  I now view this as 'I specifically tacked the wire here to change the datatype'.

Simple, consistent behavior between all loops and data types.  No need to guess my intentions since I spell them out explicitly.

[johnsold]

I think it might be better to use the nature of the sink to determine the tunnel type. Wire through the loop boundary to a scalar sink (indicator terminal or input to function or VI) and you get Last Value. Wire to an array sink results in auto-indexing. Of course a mismatch will produce a broken wire. Tacking to the boundary or terminating the wire without a connection outside the loop produces the effects which now occur. 

This method allows the programmer to explicitly tell LV what the data will be doing without adding any extra actions, so it should improve productivity.

This would be less of a change from current behavior. I think it would be more quickly learned and accepted by people accustomed to the existing system.

Lynn

[Darin.K]

Upstream type propagation can be fraught with peril, polymorphic inputs in particular could have interesting effects.  What if you are wiring to Add, for example.   That is one of the reasons I typically prefer explicit methods over "smart" automatic methods.  

[JÞB]

In principle I agree that some better tunnel type "Smarts" might be in order.  But, I can't say I agree that dragging a scalar wire across a For loop boundry should default identically to dragging a scalar wire across a While loop boundry.  In many cases (e.g. Error Out, Refnum) I would prefer a SR on a For Loop and a Last Value on a While Loop.

[Darin.K]

This idea is removing "smarts" not adding them. 

<OT>

If I want a SR then most times I simply wire a loop and convert the FN to a SR.  done and done.  Now if they fixed the FN then the conversion would not even be necessary.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/An-output-terminal-for-feedback-nodes-that-mirrors-the...

With conditional autoindexing in place I consider this one of the biggest, if not the biggest syntactical hole in LV.

</OT>

[johnsold]

Darin,

I had not thought about polymorphic inputs.  With those it would probably only be practical to use a default behavior, even if it is wrong more than right.

Maybe an environment option to allow the programmer to select the behavior could be considered.

Lynn

[Darin.K]

@Lynn, could you elaborate on the issue you are envisioning?  I may need another cup of coffee but I am not seeing it. 

If you were to pull a scalar out of a for loop and try to wire it to Index array directly you would get a broken wire, but you can already click that wire and 'Enable Indexing at Source'.  Likewise if you pull a scalar into an array input you can 'Disable Indexing at Source'.  Of course these options should be improved (they are limited in scope now to array primitives), but the mechanism is there.  After a few trips I'll wager it becomes second nature to get it right the first time.

Even if you wind up with the same number of miswirings, there is an important distinction for me.  I have learned to live happily with my own mistakes, if I screw something up it is on me.  I get a bit miffed when I get a screw up from the LV IDE trying to guess what I wanted to do. 

There is a style to the LV IDE which lags far behind other IDEs that I use.  Things like Intellisense anticipate the choice you are making and often very effectively narrow the choices.  You still get to decide, but the choice is within the workflow.  LV most often looks at what you have done, and tries to clean up after you.  This leads to a lot of "no really, this is what I wanted to do".  Right now when you pull a wire across a loop boundary you are making a choice to index or not, this idea let's you make that choice as you are pulling the wire.  The current method makes a choice for you and forces you to come back and clean up the mess.  And while I think the new conditional/concatenating terminals are one of the best new features in a long time, their side effect is that the enabling/disabling of autoindexing involves a longer menu now (you have to enter a submenu).  In fact, that is probably what brought this idea to a head, the change made my workflow much harder so I finally noticed the pain.

[johnsold]

When I suggested an environment option I was thinking that Preferences (or Tools >> Options) could have a selection on the Environment page or the Block Diagram page to choose the current behavior, Always Last Value, Always Autoindexing, the tack wire method which you propose, or some other option.

I recognize your valid concern about upstream type propagation, but in cases where the connection is unambiguous, such as wiring to a scalar terminal (indicator or non-polymorphic function like index on Array Subset), the tunnel type matching the sink would save a few clicks.

Lynn