We use .ini files to store messages for dialog boxes, and since many of our deployments are international, I modified the config file functions in vi.lib to allow us to use Unicode config.ini files. Initially I only put in enough functionality to serve the specific needs of our dialog boxes; however I have been slowly expanding it and now have a full set of config file functions that support ASCII, UTF-16 Little Endian, and UTF-16 Big Endian config.ini files.
I would like to share the code, but because it is based on NI files in vi.lib, I am unsure about licensing issues. I think it would be OK to share because my code could only be used by people who have a LV development system, and therefore already have legit copies of the original files.
Does anyone know if it's OK to share modified versions of files in vi.lib?
Here is the Enhanced Config File Functions library.
These files provide enhanced functionality for handling config.ini files. Instead of using the config file funcions in vi.lib (palette -> File I/O -> Configuration File VIs), use the like-named top-level VIs in "Enhanced Config.llb", or access them via the "Config Main" folder in "Enhanced Config.lvlib". Note that this library is not yet complete: The functions “Remove Key.vi” and “Remove Section.vi” are not provided. Also, the function “Not A Config Data Refnum.vi” is not provided, however the version in vi.lib will work with these new functions.
You can have this for free (and it's worth every penny!), but I offer no guarantee that it all works as it should.
Use it at your own risk.
There are 2 enhancements:
1. Support for Unicode config.ini files. The following file formats are supported:
ASCII, UTF-16 Big Endian, and UTF-16 Little Endian. (You can create Unicode files with Notepad).
"Open Config Data.vi" outputs an enum that tells you the file format.
Also, when using it to create a new config.ini, you can specify the format.
When sending strings to the functions (Section Name, Key Name, Key Value), you may use either ASCII, or UTF-16 BE, or UTF-16 LE, regardless of the format of the file. Of course if you have a Unicode config.ini file and you have Section and/or Key names using codepoints > 255, then you would have to use UTF-16 BE or UTF-16 LE to specify the Section/Key. However if the Section/Key names your Unicode config.ini file only use codepoints < 256, then you can specify them with ASCII.
Strings that are output from the functions (Section Names, Key Names, Key Values) will be either ASCII, or UTF-16 BE, or UTF-16 LE depending on the format of the config.ini file. You can determine the format of an ASCII, or UTF-16 BE, or UTF-16 LE string using "Unicode.llb\Remove Unicode BOM.vi". (Note however that there's no way to distinguish between a Unicode string without a B.O.M. and an ASCII string.
Since creating Unicode block-diagram constants can be a bit tricky, I've included some utilities to help you. See "Utilities.llb".
Note: In the documentation and label names of VIs:
2. Improved support for multi-line keys. This makes them more human readable in the .ini files:
Originally, multi-line keys had to be like:
KeyName = "Line 1\0ALine 2\0A\Line 3"
Now they can be like:
KeyName = "
To have a multi-line key in the new format, a newline must immediately follow the opening quote.
Here is the finished off version (now includes “Remove Key.vi”, “Remove Section.vi”, & “Not A Config Data Refnum.vi”). Also a little bit of cleanup.
There is an error in the ReadMe.RTF file in the .zip file. It incorrectly stated that string output from Read Key would be "either ASCII, or UTF-16 BE, or UTF-16 LE depending on the format of the config.ini file." In fact, when reading strings from a config.ini file with Read Key, the output will be "either ASCII, or Unicode BE, or Unicode LE depending on the format of the config.ini file.; meaning that it will not have a Byte Order Marker (B.O.M.). A corrected ReadMe file is attached.
First thing I tried was to save an example file with BE encoding. But the example failed...
Seems to me there is a bug in "Parse Config To Queue.vi". In case "þÿ" ("Unicode BE BOM found Place in Brackets on separate line"), the first string is 5B 00. This prevents the example from returning data. It works fine when this is set to just 5B...
Thanks for finding that. Attached is an updated version. In addtion to fixing the bug you found:
I'm working on a OO config library. Your work triggered me to add (continue working on) Unicode support.
This is just FYI, not a critic or advice... But since you triggered me, maybe I'll trigger some ideas in return (for you or others).
My main goal for the library is to:
+ add regular expressions to get\set\delete\modify keys and\or sections,
+ add tools for variant data (including clusters and 1D arrays),
+ add tools for references,
+ add tools to work with comments, empty lines, etc.,
+ work by reference or by wire,
+ be persistence when the code is stopped for debugging,
+ and to be easily extendible and\or modifiable without duplicating code.
The last point is, as you found out, a big problem with the NI library. Copying is the only way, and far from ideal.
My design for Unicode support will be quite different though.
Instead of using the data inside the file and preceding it with BOM's, my implementation will convert UCS\UTF-16-LE, UCS\UTF-16-BE and UTF-8-BOM to UTF-8 when the file is loaded. This is what LabVIEW uses, so the library doesn't need any adjustment. When saving, the UTF-8 data is converted back to either the original format, or the format specified. That's the plan anyway, but it seems to work out.
The result is that when you read the 'hello' key, the Chinese text will appear in the result string (if the Chinese code page is used of course).
It's fully operational (except Unicode support and other wild ideas). At some point this will be released in the tools network. Most likely for free (or donationware). Making a decent manual and documentation is stopping me (, as usual)...
Hey Paul, has this resolved the issue you made this forum post for?