Why the input data clear when i close the program?

[45122435366]

hi

plz help me...

I enter input data in the array. but when i save and close the program and then open it, the data lost and clear !

i want the input data i enter in the numeric control array remain and not clear when i close it.

Thank...

[altenbach]

menu ... edit... make current values default ... save VI.

(... or right-click array...data operation...make current value default... save the vi)

(see also this idea for an extension of the functionality)

[mikeporter]

The solution that Christian gave answers your question, but you might want to think about whether that is really what you want. Saving data as the default value does indeed save it, but it also adds the size of that array to the size of the application and if the array is large, that can be a lot of memory. In addition, it means that if those values change you need to modify your code. Note, I am not saying to not do it, just that there can be unforseen consequences.

An alternative is to save the array in a file or database and have the application code start by reading the file and loading it into the array.

Mike...

[natasftw]

If we're worried about size, why does it matter if we have the data stored as part of the application or part of a database?  The values take up space either way. 

The only value I can think of in terms of space is offloading the data to another PC.  But, we're still taking up the space.

OP, you've got several ideas now.  You can maintain the data elsewhere.  You can set it to default.  But, you can't just close it and hope it'll appear.

[altenbach]

Saving default values for controls is an important skill and has many uses. For example a subVI will use the default value for a control ( assigned to the connector pane) if it is not wired from the calling VI. Many times (e.g. in an action engine) there is one mode that is used in 90% of the calls, so it simplifies the code if only the exception uses need to be wired. (Just document it!). (Side note: Opinions matter, though and there are users here that are big proponents of having all connectors defined as required. I prefer to have as many inputs unwired for typical use but that's a different discussion :D)

Another use would be to have the default containing a special sentinel value (-1, NaN, "unwired", etc.) so if the value occurs, the subVI knows that the control is not wired and can act accordingly.

You definitely don't want to do it for controls and indicator containing huge amounts of data (arrays, graphs, etc.) so there is a good reason that VIs don't save data you enter unless you manually define it as default data. Imagine you call a subVI with 1GB of data in an array and later save it. You definitely don't want the subVI to save with all that extra baggage taking up your entire flash drive. 😮

During development and debugging, it is important to save it in a state that produces useful results so we can run it and test it after all code changes. If all controls are zero it is tedious to first enter values, making sure they are all actually reasonable. An input with all zeroes and empty arrays is often not useful for testing. Even if there are array inputs, I often have some default values e.g. a 3x4 2D array that produces a known result for quick verification that code edits didn't mess things up.

What we often see in the forum is an attachment containing a huge problem VI with all inputs zero and we have no idea what typical values are or even how to use the VI. If the controls contain typical settings, it is much easier to troubleshoot, because we can just run it out of the box.

[natasftw]

I'd be more than happy to agree there are use cases for saving the values in controls/indicators. 

My curiosity stems from the idea that it's worthwhile to save space by offloading the values.  Let's say we offload them to a binary file.  In that case, we've still created a slight increase in the footprint required on disk to get this data back into the application.  If we don't use binary, the overhead increases.  If the data takes 1GB on your stick, it still takes at least that much space.  We haven't eliminated that.  We've just moved it from the VI to a binary file instead.

The values must exist somewhere.  If size is our only consideration, how does splitting the same space into two files help that?  Am I missing something obvious?