GenINI - generate read/write code for INI files

[jzoller]

Over time, I've found writing INI files (section followed by key/value pairs) to be easier than writing the LV code to read and write the INI files.

So, here is a small tool to automate the generation of code for reading and writing existing INI files.

• Download zip, open project, open and run GenINI_Main.vi.
• Point the top file control to an existing standard INI file (like the one included in the Test folder, for instance)
• Click the "Read File" button, and select the Key Type for each entry from the INI file.
• Click the "Generate Code" button to spit out the read and write VI's (saved in the same folder as the INI file).

There are a fair number of limitations and possible enhancements, but I would love to hear any feedback people might have before I complicate this too much.

Thank you kindly,

Joe Z.

GenINI.zip

Edited February 14, 2010 by jzoller

[Jim Kring]

Very cool!

[JoeC]

Nice Code.

One suggestion would be to have the generated read code (INI_Read_Test) create a file if necessary set to true instead of false. This would allow for the creation of an ini file if the ini file was not present.

Edited February 14, 2010 by JoeC

[SAS]

Good one. One immediate suggestion would be to design- not to repeat the section name for every key!!!

[jcarmody]

 I love it.  This'll go in my LabVIEW\project folder.

I like using the OpenG config file VIs but still have had to make the typedef cluster.  Excellent idea.

Thanks,

Jim 

[jzoller]

Nice Code.

One suggestion would be to have the generated read code (INI_Read_Test) create a file if necessary set to true instead of false. This would allow for the creation of an ini file if the ini file was not present.

Hi JoeC,

That was actually a style choice: I couldn't come up with a use case where I wanted to try to read a blank INI file. I would rather throw a "missing file" error.

Of course, it's an easy mod to make if you prefer the creation: just set the file create flag in GenINI_Read_Template.vi to true.

Thanks for the feedback,

Joe Z.

Good one. One immediate suggestion would be to design- not to repeat the section name for every key!!!

Hi SAS,

I seriously considered doing that. To do it right, I think I would want to unflatten the data to have another level (that is, an array of Section clusters containing a Key Value pair array).

In the end, I made the decision that the extra constants were easier to live with than the extra complexity in the generation code.

Thanks,

Joe Z.

I love it. This'll go in my LabVIEW\project folder.

I like using the OpenG config file VIs but still have had to make the typedef cluster. Excellent idea.

Thanks,

Jim

Thanks!

I'll look into the ability to abstract out which config files are used... <famous last words> it looks pretty easy </famous last words>

Joe Z.

Edited February 15, 2010 by jzoller

[jcarmody]

[...]

I'll look into the ability to abstract out which config files are used... <famous last words> it looks pretty easy </famous last words>

Joe Z.

I wasn't referring to the OpenG alternatives to the NI VIs, I was thinking about the Read and Write Ini cluster VIs.  This snippet uses the Read Ini Cluster VI and the typedef from your program to do read the ini file in two steps (you'll need to convert the variant).  I don't think there's any need to abstract out the config files, unless someone else has a use-case, because I'm only going to use the typedef control. But I'm going to do that every time I have a config file so your work will help me a lot.

[Yair]

The code for generating the typedef and code itself is simple and nice, but there's absolutely no way I would stop using the other solutions (such as the OpenG VIs shown earlier or the MGI VIs) to use this.

This will be difficult to read, difficult to edit and no easier to work with than the other solutions (see Jim's snippet which shows how easy it is to use them, and it becomes even easier when you need to add elements to the cluster).

[jcarmody]

The code for generating the typedef and code itself is simple and nice, but there's absolutely no way I would stop using the other solutions (such as the OpenG VIs shown earlier or the MGI VIs) to use this.

[...]

Yair,

The beautiful thing is that Joe's solution makes the typedef constant to use with the OpenG VIs. My current workflow has me creating/editing an ini file and then creating/editing a typedef'd cluster. This makes the cluster for me and, as long as I can fit it neatly in my LabVIEW\projects folder, I see myself using it whenever I need to work with config files.

What does MGI have for this?

Jim

[crelf]

Moderator note: Topic tweeted to @lavag

[Yair]

My current workflow has me creating/editing an ini file and then creating/editing a typedef'd cluster.

If that's what you want. Personally, I find it much easier to create the cluster in LabVIEW (and safer. No chance of typing something wrong). Also, when it comes the time to add an element to the cluster, it seems to me that this solution is harder than simply editing the cluster.

What does MGI have for this?

MGI has VIs which are very similar to the OpenG VIs. They are much faster, but they only work on an entire file at once (so you can't work with just part of an INI file) and they only work in 8.x.

[jzoller]

The code for generating the typedef and code itself is simple and nice, but there's absolutely no way I would stop using the other solutions (such as the OpenG VIs shown earlier or the MGI VIs) to use this.

This will be difficult to read, difficult to edit and no easier to work with than the other solutions (see Jim's snippet which shows how easy it is to use them, and it becomes even easier when you need to add elements to the cluster).

I can't disagree...

But let me propose some alternative thinking.

First, dependency on external code libraries can be difficult, especially for validation and package maintenance. A fully "native" solution avoids this. (Yes, I know that there is no actual difference, but clients are not always reasonable.)

Second, in my heretical opinion, the generated code should not be maintained. At least, not at the wiring level. If changes are necessary, the code should be regenerated, not tweaked by hand. In other words, generated code should almost never be read, and so readability of generated code is no longer as important.

Now, please note, this isn't to excuse sloppy wiring. Hopefully, the wire cleanup algorithm will improve with time so that the generated files are cleaner, and reduce to the final solution in one step.

Thanks,

Joe Z.

[Yair]

Second, in my heretical opinion, the generated code should not be maintained. At least, not at the wiring level. If changes are necessary, the code should be regenerated...

The first part certainly sounds reasonable, but the question then becomes "How easy is it to regenerate the code?". With the OpenG VIs it's very simple - you open the typedef and add another element and you're done. With this, you will presumably have to edit the INI file and then regenerate the VI (with the same name) while working around issues like SCC checkouts, an icon, documentation, etc.

[James~Liu]

I like this,

thank you

[CT2DAC]

I see it's quite sometime this has been posted, but only now I ever come accross it (although I have long been interested in programmatically creating data structures from "end result files" instead of painstakingly jotting down every cluster, field, subcluster, array, etc.).

EXCELLENT piece of work!!!!!!! A lot of stuff to learn from!

Thanks.

 

Edited June 21, 2023 by CT2DAC