Set index inputs on LVOOP array element accessors to Required

[tst]

I almost never use accessors for array elements, but recently I did and I found something I didn't expect:

The index inputs on the accessor VIs are set to recommended, so you might not notice that you didn't wire them in. I expected them to be required.

I checked and found out that this is a design decision - it was done that way because that's how the Index Array and Replace Array Subset primitives behave - they don't require you to wire in an index.

However, the argument could be made that those primitives behave that way because they can be expanded (although they apparently behaved the same even before the expansion feature was added).

In addition, the In Place Element Structure does have the index input set as required, so LV already has a counter-example built-in.

Since it's basically a choice between two valid scenarios, NI needs user input to decide, so that's where your votes come in.

Personally, I think it's less important what other features in LV do and more important to allow people to safely and conveniently use my classes. I would expect that in most cases I would want the inputs to be required, so that's the idea here - Change the index inputs on LVOOP array element accessors to be required by default:

[jgcode]

I prefer required by default. I leveraged Custom User Scripts to do this: http://lavag.org/files/file/102-lvoop-custom-user-scripting/ I also prefer the element and index swapped positions, by hey that just me - alternative!

[SteveChandler]

What about something like this? Maybe instead of a listbox entry it is a checkbox or radio button somewhere. Basically specify at creation time.

[SuperS_5]

I was on the fench about this, untill the idea by Steve Chandler, above.  I vote for that implimentation of this idea.

[AristosQueue (NI)]

SuperS_5: You're free to put that as a new idea on the forums, and we might do it someday, but the easy flop of the template is one that could be done in the next few weeks and make it into LV 2012. Anything that requires UI change and actual code is unlikely unless it is really high priority fixes or adjustments to other already-approved new features.

[Daklu]

Wow, lots of people in favor of the change.  Me... not so much. 

The problem isn't that the index terminal is set to Recommended, it's that it didn't follow tst's expectations based on his Options settings.  The solution to that is what he said earlier... make it so the terminals match the Options dialog.  Transferring the inconvenience of changing the conpane to somebody else doesn't strike me as a real solution to the problem.

Sorry tst... I can't get behind this one.

----

Personally I'd prefer the ability to be able to substitute our own templates or scripts in place of the built-in abilities.  Then we could customize each of them to our heart's content... and I could get rid of those error structures in the accessors.

----

Also, I don't buy the argument that it is inherently "safer" to start it as required.  Sure, you'll get a compile error if it isn't wired, but I suspect it's fairly rare for most experienced developers to forget to wire an input.  The bugs I write tend to be logical errors, not syntactical errors.  In fact, when an input is not required I am much more likely to spend a few brain cycles considering what will happen if the default input value is used than I am if the input is required.

[Albert.Geven]

compilers that spot stupidity errors have saved more them then you can think of. It seldom is the difficult part of a program that is wrong but the standard mistake made, or wire forgotten that takes a long time to find.

[tst]

> Transferring the inconvenience of changing the conpane to somebody else doesn't strike me as a real solution to the problem.

Well, it solves my problem. 😉

(And if this idea is ever implemented, it will probably be the problem of most users).

> Sure, you'll get a compile error if it isn't wired, but I suspect it's fairly rare for most experienced developers to forget to wire an input

In this specific example, I was preparing code for someone else and he was supposed to add the index later when he would create some additional code. I could probably have added some comment or something which will draw his attention, but I wasn't thinking about it at the time. Technically, it's probably his fault for failing to notice that (at least I think he forgot to, it's possible he didn't and that this just annoyed me), but I want LV to protect me from things like this when applicable (and in my case I think it's applicable for most subVI inputs).

[SteveChandler]

@Daklu "Personally I'd prefer the ability to be able to substitute our own templates or scripts in place of the built-in abilities.  Then we could customize each of them to our heart's content... and I could get rid of those error structures in the accessors."

You can get rid of error clusters in accessors. In the create accessor dialog expand the advanced options and unselect 'Include error handling terminals'

[AristosQueue (NI)]

Daklu: I do *not* think these should follow the Tools>> Options settings. This is not a case of creating arbitrary new terminals on VIs. This is a case of creating VIs from specific templates. They should follow whatever the template its defined to be, whatever we decide that should be. 

Based on everyone's feedback, I am going to make the change to the templates to make them Required. I do *not* promise to get this into LV 2012, but I am going to ask, seeing as it is a very straightforward, low risk change that doesn't require any documentation changes or secondary features to be modified. It definitely will NOT make it into the first 2012 beta, but if it gets approved for the release, you'll see it in the second beta. If it isn't in the second beta, you'll know it got pushed to 2013.

In the meantime, tst, you can go ahead and modify the VI templates on your own machine. resource\Framework\Providers\LVClassLibrary\NewAccessors\*.vit -- there are four files you need to modify.

[Daklu]

First, let me say the proposed change doesn't affect me much, so I'm not super passionate about the issue.  That said...

AQ:

I see your point, but I think you are making a distiction based on how the features are implemented, not on how they are used.  From the LV user's perspective, there isn't much difference between having LV automatically create a sub vi from selected code and automatically creating an accessor for class data.  In both cases LV does its magic and the sub vi appears.  However, 'Create Sub VI' follows the Tools > Options setting while 'Create Accessor' does not.

When it come to usability, consistency counts for a lot.  (See The Principle of Least Astonishment.)  The current behavior is consistent with the Index Array function.  Making it follow Tools > Options is also consistent, but in a different way.  In both cases the behavior is consistent with some larger, related feature of Labview.  Making the terminal Required is consistent with... the IPE structure?  How is that intuitive for users?  Is it less astonishing than the other two options?  Seems like a big step backwards in usability.

Like I said, this particular change isn't that big of a deal.  My concern is that it appears the decision is being made because it's more convenient for a handful of users rather than because it's the right decision.

tst:

"Well, it solves my problem."

Can't fault you for throwing the idea up.  I'm sure I have several ideas here that are asking NI to change LV to fit my coding idiosyncrasies.  🙂  However, I *can* pick apart your argument for the change (though you did a pretty good job of that yourself.)

"In addition, the In Place Element Structure does have the index input set as required, so LV already has a counter-example built-in."

Given that the IPE structure is (presumably) used less often and is newer than the Index Array and Replace Array Subset functions, I'd say requiring an index wire on the IPE is a bug, not justification for changing the behavior of other features.

"While it's true that the accessor VIs technically [operate on arrays] as well, I feel that it's usually a more specialized case of array access, where the user will usually want to use a specific index."

One thing I've learned about users is that it is impossible to predict what they will want to do.  Especially for something with a diverse user base like Labview.  Making assumptions about what they will want to do rarely works out for me.

"Making the control required makes you more likely to notice this if you want to change it back. I prefer safety."

Safety seems to be the reason most people are on board for this change.  Is "safety by default" a guideline NI should use for all decisions?  You said you wouldn't change the Index Array function, but isn't it safer to require at least the first index terminal be wired?  I know NI likes to design with inexperienced users in mind, but do we really want them to put training wheels on everything?

Lots of times I prefer in my code safety too.  In this case you wanted your API to have required terminals to help prevent users from making a mistake.  Nothing wrong with that; however, I think you'll agree it doesn't logically follow that the best decision for your api is also the best decision for Labview.

Steve:

"You can get rid of error clusters in accessors."

I want the error in and out terminals on the conpane.  I don't want a case structure on the block diagram.

"But in all seriousness it seems odd to have anything unconnecte in an object accessor or method."

It's not uncommon in my code.  Not exactly common--but not uncommon either.

Albert:

"It seldom is the difficult part of a program that is wrong but the standard mistake made, or wire forgotten that takes a long time to find."

My experience is exactly the opposite.  Sometime I do forget to wire something up, but once the bug is discovered finding the root cause is usually pretty quick and easy.  What makes the difficult part difficult is that it's hard to get it right.