placing ConfigFile-VIs with VI Scripting

[comrade]

Maybe I am missing something here, but when trying to create ConfigFile VIs as to be found in vi.lib\Utility\config.llb I was unable to find these functions in the "type" input ring control for "create New VI Object".

I tested a bit and learned, that some of those VIs are not even listed in the "SubVIs[]" property of the diagram reference of a VI containing such ConfigFile VIs, see attached AccessConfigVIsWithVIscripting.vi and, as the test object, testScriptConfigVIs.vi.

As I deem VI Scripting to be a perfect way of automating the development of INI read/write functions from existing INI files, I am stumped now to do exactly this. I just hope I am seriuosly overlooking something obvious here. Can anyone point me to my flaw in thinking?

[tst · Accepted solution]

I see two flaws in your thinking -

1. These don't appear in the list, because the list only holds primitives and these are not primitives - they're VIs. If you want to drop them, you need to use the path input.
2. The reason you don't see the VIs in the list is that you're looking at the top level diagram and the VIs are not inside the TLV - they're inside the loops, which are considered separate diagrams, which you have to drill into. The scripting palette includes a VI which will do all this parsing for you, so it's a much better option if you're looking for all the instance of class X. It's important to understand how the diagram is constructed and what the different elements are if you're going to do scripting.

More generally, I would suggest using something like the OpenG variant config VIs or the MGI read/write everything VIs, as they don't require new code for each thing you want to do. They do have their own problems, but they are generally useful.

Also, if you want, I'm sure I have seen code which does build code to read and write from INI files. I seem to remember seeing one on the LAVA forums some years back.

[graPI]

You do not need type to create them. Reference to this item via path.

[comrade]

Thanks, tst and GPiotr. I did miss the path input of "New VI Object".

As for recursively parsing into the diagrams of the loops - I thought I did exactly that with the lowermost For Loop - still the Read Key-VI didn't show up in the indicator labeled "Array".

Either way - good to know about the "path" input. I'll go now and have a look for the ConfigFile VIs you mentioned, tst.

[tst]

comrade wrote:

As for recursively parsing into the diagrams of the loops - I thought I did exactly that with the lowermost For Loop - still the Read Key-VI didn't show up in the indicator labeled "Array".

Generally, recursion code will have to have actual recursive calls or something iterating over a stack which replaces the recursion. If you don't see either, you're not recursing.

But to be more specific as to your problem here - it's a misunderstanding of both the Terminals[] property and the Diagram property. The property you're looking for is not in the Node class, but in the Structure class. I would suggest you read the help for the relevant properties and also that you play with it, because like I said, an understanding of the structure of the diagram is critical if you want to do scripting.

[rolfk]

And solving this with scripting is a sure way for headaches in the longer run. You'll have to hardcode the VI names (and likely the paths) in your scripting solution and that is very easy to break if NI decides to overhaul the INI VI's. They have mechanismes in place that allow for this kind of modifcations by executing special mutation tables when you upgrade a VI from one LabVIEW version to another. This includes things like rewiring nputs and outputs, adding compatibility code into the calling diagram and also relinking to VIs with changed name. This mutation tables get not triggered when you do your own scripting and the resulting code will simply be broken.

The OpenG Variant Data Tools and the according INI File extension are a much safer and ready made solution.

[comrade]

Thanks for both your thought, rolfk and tst. Looks like I'll go back to school on this