Aside from tagging VIs for code maintenance purposes, I was wondering this morning if I shouldn't experiment with VI tags to replace INI settings that could be changed by the user, but only from the UI. I've seen comments that it would be more secure under certain circumstances.

Any thoughts as to how smart a move that would be in general?

I already hear that it's nice to see quickly from a text file what are the settings and I agree. But what about making sure ini keys are properly set? Changing them from inside the VI could enforce that. Besides, there is no way the file could be missing altogether... VI tags are easily found in Invoke node and can contain any data type. (I can foresee a nice OpenG set of VIs for that...)

You cannot set tags in the runtime engine because you cannot change the VI (there's no ability to Save).

It works on library though. Will there be any way to save them for VIs in the future?

In LabVIEW 8.6 there is a small set of VIs that deal with VI and object tags. They are located at [LabVIEW 8.6]\vi.lib\UserTags. Let me know if you have any feedback on them.

-D

If you are worried about the user editing an INI file and putting in bad values, my solution is to use a small XML file and an .XSD (schema) file. When the app boots, it reads the xml file for its 'ini' settings. I first validate the XML against the schema to verify it has no errors. If they messed up the XML, then the app will report the error and what line is invalid, then exit.
This is not that hard to do if you have used any .NET functions before in your LabVIEW code. I can post some examples if that would help.

-John

Can you post an example. It would be helpful, though I may not be able to use for RT apps where I read ini settings from xml.

Thanks,

N.

Honestly, it was more a thought experiment kind of question. I recently used lvclass tags when I was playing with cloning classes programmatically. I was wondering if VI tags would be an efficient way to go. Based on AQ's answer, it is not practical at the moment, since it cannot self-modify its own tags, so I'll let that go.
I admit that XML has some appeal, especially since it supports LabVIEW classes in 8.6. I'd welcome your example VIs. thanks

Sorry it took so long. I had to make a generic version and add some comments. I posted it in the code repository in development section. Here is a link:

XML File Reader in CRID

Well... It's not too bad, the fact that the tags can't be modified is a security, no ?
I mean.. you can store the default settings into tags and in case the INI has been removed / screwed by someone, then load the default settings from the VI tags, no ?

No - it's because you can't edit a VI in the RTE. For example, you can open a VI, edit it's diagram or front panel, then save it - tags are part of the VI, so editing the would be like trying to edit the diagram.

Yes. I assume it's for the same reason that you cannot change the default value of a control at run time.

What I was meaning by "the fact that the tags can't be modified is a security, no ?" is that, in a way, being sure that it will not be modified whatever happens can be interesting for storing default values.
Often default/last used values are stored into an INI file, what if the operator deletes or moves the INI file ? Well load the default value fron the VI tag you are sure no one will screw the VI tags .
This is what I meant by "security".


Is there a transparent-babel fish-like animal we could stick into our eye to understand anything written in any form of language ?
And what if I stick 42 babel fish into my ears, would it work ?

That's right.


Ahhh - I get your menaing now. Yes, you could store constants as tags, but what benefit would that have? Why not just make them constants on the diagram? Unless you're trying to hide the constants?


sounds like a pretty intense game of Chinese Whispers where language is involved too

Right, no point... other than hiding the constants, so no real point.
Just thinking out loud