How can I make controls save their state when the project is closed?

[chuggins1434]

While I didn't go through all of the vi's attached I know you can do this easily with Write to Spreadsheet.vi... write it to a txt file, which you can open with Excel to edit quite easily and then just read from the file at open.  I do this with my current DAQ system several hundred times a day... write to the text file, read it, and delete it, in my case.  Just make it a tab delimited txt file and you're good to go.   You can even throw a few macros in Excel that'll make life easier such as one to read the file and drop the data in Excel and one to write it back once you're done editing it. 

Good luck!

Chad

[pjr1121]

There are a few ways to do this with external files.  You can read/write to a Configuration File, which would have a place to store the values of each control.  This may take a bit of effort on your part but is probably the best option as the configuration files are easy to read/edit.  In my programs, I typically group all of my controls on one side of the screen and place them in a cluster.  This cluster can then be easily written to an XML file with just a single wire.  The XML option becomes more challenging if your controls are scattered or in multiple locations.  Or, you could manually write values to a txt or dat file (not as easy to deal with).

I personally use property nodes to update controls upon initialization and I update my code often so Block Diagram cleanliness is important.  Often times you will find that you are required to access certain controls in numerous locations in your code and it becomes rather messy to run wires all over the place.

[DroidFreak]

The difference is that text-based programming languages focus on giving you the tools to code things yourself while graphical languages focus on giving you pre-built modules. It's a whole lot easier to write your own code from the bottom up in a text-based language because the rules are usually simple and well-explained. In a LV, wandering off the beaten path of what NI made high-quality modules for will leave you surrounded by complicated, unexplained rules and menus that offer scores of unexplained options.

[nathand]

---

@DroidFreak wrote:

... will leave you surrounded by complicated, unexplained rules and menus that offer scores of unexplained options.

---

This is how I feel every time I start digging into C# assemblies.

You're in a LabVIEW forum. You are unlikely to find too many experienced LabVIEW users here who agree with you, but we would be happy to help you develop a familiarity with LabVIEW so you don't feel this way. The LabVIEW rules are simple too, you just have to get accustomed to them. And they're a lot less arcane than in C - you'll never have a syntax error during compilation in LabVIEW, or have to hunt down a mismatched bracket.

[tst]

---

@DroidFreak wrote:

In a LV, wandering off the beaten path of what NI made high-quality modules for will leave you surrounded by complicated, unexplained rules and menus that offer scores of unexplained options.

---

I don't agree with that characterization at all. LV is a programming language just like any other - if you know how to use it, you will write good code (just like NI sometimes does). If you don't, you will write bad code. We seem to manage, so obviously it's perfectly doable. If you know LV, then the rules and options aren't unexplained - they make perfect sense (at least most of the time), but like any programming language, it takes time and effort to learn all the details of both the language and the IDE.

Now, it's true that languages like C generally give you more freedom, but a) that comes at a price and b) many more modern languages have chosen not to pay that price. I can certainly say that you are not limited only to what NI makes. There are certain things which LV won't allow you to do, but I don't think you're even close to that border.

Frankly, I feel it's just a matter of personality. I've learned several text based languages before using LV, but I found that I like LV much more and can follow it much more easily. I know of people who just can't figure it how it works at all.

[billko]

---

@DroidFreak wrote:

The difference is that text-based programming languages focus on giving you the tools to code things yourself while graphical languages focus on giving you pre-built modules. It's a whole lot easier to write your own code from the bottom up in a text-based language because the rules are usually simple and well-explained. In a LV, wandering off the beaten path of what NI made high-quality modules for will leave you surrounded by complicated, unexplained rules and menus that offer scores of unexplained options.

---

If, by "pre-built," you mean the stuff on the palettes, they are no different than keywords and operators in a text-based language - except that I can string together nodes fater than I can type in a string of keywords and operators because I suck at typing.

Consider this: "While loop."  Draw one on the BD and fill it in.  In a text-based language, (pseudo-code) "Do," "While," and type all your stuff in between.

"Unexplained rules, menus, options?"  Have you ever looked at the Help files for Visual Studio anything?  Compare it to the LabVIEW context and help file.  To me, the LabVIEW help file is MUCH easier to understand.  It is written in plain English.

So really, it's all a matter of perspective.

[0utlaw]

Hello All,

I may be a little late to the party, but wanted to mention that there are VI Scripting properties for configuring default values, specifically the DefVal Property.  More information on this can be found in these help files (due to the data type requirement it appears there is one version per terminal type):

NI.com Search: DefVal

http://search.ni.com/nisearch/app/main/p/bot/no/ap/global/lang/en/pg/1/q/defval/

You'll need to enable VI Scripting before the option appears as per this document:

LabVIEW Help: Enabling VI Scripting

http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/enabling_vi_scripting/

VI Scripting isn't trivial, and keep in mind that these properties are edit-time only (they cannot be updated while the VI containing the front panel controls or indicators is running, which is why this is a VI Scripting-only property) so you'll need to write a separate function that obtains terminal references from the VI you want to update, figures out the data type of the terminal, and sets the default value to the current value.  This may be more trouble than it's worth to create a "usable everywhere" utility, but if you just want to update values in an otherwise static front panel where your data types are known it probably wouldn't be too bad to code. 

Do be aware that enabling VI Scripting exposes even more arcane functions than you'd had access to previously, so if you're not fairly comfortable with the environment I'd recommend disabling it again once you've got a DefVal property node you can copy and paste around.

Hope that helps! 

[tst]

Tom, I wouldn't bother with the scripting property because there are other non-scripting methods which work just fine (such as the VI's Make Current Default method, which will work on all controls in the panel), but like I said earlier, they all require saving the VI and now I see that at least that one also requires that the VI be idle.

Just to show that there's no reason to consider to be difficult, here's what I usually do, which is basically similar to what was discussed here:

https://decibel.ni.com/content/docs/DOC-15349

This isn't the actual code I use, but it's close enough. I don't think you can get something which would be much simpler than one function for reading and one for writing (although I recently heard that .NET has a feature where you can configure such property directly on UI elements and it takes care of it itself. While something like that sounds nice, and I could probably write something similar with tags, I don't think it's worth it because I don't use this functionality that much).

[billko]

---

@tst wrote:

<mega-snip>

...(although I recently heard that .NET has a feature where you can configure such property directly on UI elements and it takes care of it itself. While something like that sounds nice, and I could probably write something similar with tags, I don't think it's worth it because I don't use this functionality that much).

---

If I remember correctly, Visual Studio will let you specify params to make persistent, but I believe it writes a file behind the scenes.

[DroidFreak]

That looks simple, but you're forgetting the fact that LabView has hundreds of modules and I have absolutely no idea how to find those particular modules just by seeing a picture of them (or even seeing them in someone else's program). If this were text code I could easily copy it verbatim, but as it is it doesn't help me because I still have no clue how those modules are found.

Here's what I really need: A detailed explanation of where to find the modules to write to a control, to read/write from whatever file type can store numbers and strings best, and to make something execute after a loop. I can figure out the details of the module layout myself, that's programming and that's what I do. What I can't do very easily is find things in LabView's web of menus.