Allow containers to be assigned/initialized completely in a single expression

[asbo]

When setting arrays, even multi-dimensional arrays, it is possible to initialize them in single assignment expression. For example, "Locals.Array = {1, 2, 3}" will re-define Locals.Array as a 1D array with elements "1", "2", and "3". This is essentially the same as C-style initialization syntax, which also supports structs.

It would be helpful if containers could be assigned in a similar manner. For example, the illustrated container:

could be assigned completely using "Locals.Container = {True, 1, "foo"}".

Currently, that syntax generates a run-time error, "Expected Container, found Array of Containers".

The only scenario I could think of where assignment gets a little weird is with Object types, but in that case you'll have to be assigning Nothing, the return of a function call, or an existing object from another property - there's no way to define a literal value to assign there, but that's already the inherent nature of Object types.

My use case is often container initialization. There are several kludges around this - keeping an empty copy of the container and assigning it to the working copy to clear the working copy, individually listing out each parameter, and a few others. Another case is when it's useful to assign a constant to module parameter - it's debatable that may be bad form, but would still dramatically improves the ease of skimming parameters if it were implemented. It would be a slight bonus to Sequence adapter in particular, which cannot expand containers in the parameter list, as other adapter types can (go kudos Allow Sequence Adapter to expand containers in the module tab to fix that!).

[warren_scott]

I like the general idea of it, but to me it gets rather clunky especially around reordering items in containers.  Nothing really forces the containers to have their elements in a specific order, and now that reorering elements in containers is not horribly difficult, I don't want to over complicate things by needing to go through my code and redo my assignment statements if I restructure a container, especially if they won't complain until execution  (If I change a name, seq analyzer will let me know the variable name is no longer valid; if I resort it may or may not especially if I swapped the order of two strings).
I, too am used to and have just accepted having a locals.foo_default variable to use to assign stuff.
Somewhere I think there was another idea exchange to have a Reinit_to_default(locals.foo) function added to the TS API.  http://forums.ni.com/t5/NI-TestStand-Idea-Exchange/New-feature-request-ReinitialiseToDefault-command...

But what if there were a container-value-builder feature (kind of like the condition builder where there's some ugly code behind the scenes that does the work and can display it in a nice human readable short version).
you could fire it up and link the value to a type, and then build a static value for it (or maybe assign by expressions), and then if you ever tweaked that type, it would auto tweak within the container value builder (kinda like LV OOP stuff).

[asbo]

Your concern regarding element order is completely valid. I don't tend to reorder containers once they're made, so this didn't come to mind. In fact, the ability to sort properties can get a little tricky even figuring out what the sub-property ordering is, as the column sort directly affects these sub-properties (at least in TS2014 where I'm checking). On the other hand, it's worth mentioning that type changes are an intrinsic risk when relying on static initializations - the same fundamental problem exists in C where the inspiration comes from.

The only immediate solution I can think of to the issues with ordering (which would also keep the operation in a text-based expression) would be to use key-value pairings (e.g., "Locals.Container = {Bool:True, Num:1, Str:"foo"}"), but that seems like a pretty significant change to what most developers will syntactically expect in TestStand. I'm not against it, but I think the necessary of key/value would decrease the likelihood of this change being implemented.

I suppose it wouldn't be tremendously difficult to build a custom step which can handle container-value-builder feature that you're talking about. Actually, that reminded that at one point I used a property loader file to mass-reset locals under certain conditions. However, that method is a bit less transparent. It would definitely need to use the key/value concept I mentioned to keep things straight, but even then it could get stymied by more complex changes. It's more clear now that my initial idea sort of comes apart when factoring in element sorting and the general flexibility of the sequence editor.