09-21-2007 09:37 PM
09-22-2007 02:02 PM
09-22-2007 02:20 PM - edited 09-22-2007 02:20 PM
I agree about not trying to change the vi.lib files. It gets into modifying code that is rather deeply embedded about 3 or 4 sub-vi's down. By my testing, machines without the modification do handle the files just fine. The alternative would be to create a backup copy of the whole library and rename the files and use my own versions instead. I've recently installed the OpenG files and looked into them. I like the functionality they provide to be able to store and retrieve clusters of configuration data. Of course they have NI's write configuration files at the heart as well, so if they link to the original VI library then they will generate the same .ini files missing the extra lines that I like.
@tst wrote:
The idea itself is great, but I don't like the idea of changing vi.lib files (for several reasons).
I didn't look at your code, but I assume that at least in this case, the resulting files will still be processed fine by machines which don't have this modification, so it's probably not as bad, but I still don't like it.
You should probably go to the Product Suggestion Center and tell NI about this idea.
@tst wrote:
You should probably go to the Product Suggestion Center and tell NI about this idea.
Thanks, I already did this some time ago when I created a test VI to just read and close an .ini file. I found that without setting the "write configuration file" flag in the close config file VI (which defaults to True), the whole file got rewritten even though nothing had changed. That's how I stumbled across this loss of blank lines thing.
I hope NI will look into that suggestion and add it to the config file VI library in the future. It would probably need to be implemented with a flag that says "Add blank lines?" that would default to False so that the original behavior of the VI could be maintained. Since the VI that controls the appearance of the file is a few layers deeper than Close config file VI, that flag would have to be passed through a couple of sub-VI's.
Thanks for your feedback.
Message Edited by Ravens Fan on 09-22-2007 03:22 PM
09-22-2007 02:21 PM
09-22-2007 02:24 PM
They do use the original library, so you're right and they will have the same problem.
@Ravens Fan wrote:
I've recently installed the OpenG files and looked into them. I like the functionality they provide to be able to store and retrieve clusters of configuration data. Of course they have NI's write configuration files at the heart as well, so if they link to the original VI library then they will generate the same .ini files missing the extra lines that I like.
09-22-2007 02:27 PM
09-23-2007 01:44 PM
@tst wrote:
By the way, here's an example of how something like this might break - as far as I know, only Windows uses CRLF as the end-of-line char. What will happen if you use the files on other platforms? I don't know. Probably nothing, but we can't know for sure until we check or at least think about it.
That could be. It wouldn't bother me because we use only Windows computers, and only write LV programs for our own in house purposes. Thus I would have no way to test it on other platforms.
Although, if this was a problem, I think the current config file VI's would have a problem as well because the VI's are already using the CRLF as the end of line character.
09-24-2007 11:14 AM
09-22-2014 02:13 PM
Was just about to write something similar myself when on a whim I checked to see if the behavior had changed. I don't know when this was resolved but as of LabVIEW 2013 SP1 the config.llb\Write Key.vi adds an extra EOL to provide space between the sections (even if the incoming sections were unspaced). Thanks, blue!
09-22-2014 02:21 PM
This was something that was changed in the Config Files behavior, sometime before 2013. I want to say it was quite a few years back. I'll guess around LV 2009, but I don't specifically remember.