Support reading/writing config strings in addition to config files

[warren_scott]

Right now, the LabVIEW File utility for reading Configuration Files (NI_LVConfig.lvlib) are restricted to loading data from a configuration FILE.  Unfortunately, I have a case where I am storing configuration STRINGS in other locations (like in a database) and need to interpret them.  I'd love to be able to reuse this library of code to do that, and I can't quite do that without a lot of extra work.  Right now the workaround is to read the string from elsewhere, write it to a temporary file, read the temporary file, process..... (sucks to have to take time to read/write to disk, require permissions to save to a disk which I don't always have depending on permissions on system, and wastes processing time especially for larger configuration strings/files)

I'd love to just "Open Config String" instead of "Open Config File"  (and then "Close Config String" (and return an output string)).

Unfortunately because the library has internal items marked as private I cannot reuse the internal processing code without duplicating the entire lvlib and/or customizing vi.lib.

The LabVIEW XML parser library supports a polymorphic instance of the "Load" function to take either a file path OR a string input, so why can't we have the same support for the configuration file utility?

[AristosQueue (NI)]

> Unfortunately because the library has internal items marked as private I cannot

> reuse the internal processing code without duplicating the entire lvlib and/or customizing vi.lib.

That is by design. We encourage you to proceed with this duplication and maintain your own library of functionality.

Although we could support this request, it isn't a use case for the config VIs. I do not expect we will expand the use cases of this library. You're welcome to write your own library to parse the file formats.

[fabric]

For the record, I've also needed to duplicate part of the config file library to extend the existing functionality. (In my case it was to read/write encrypted files...) I also found the private-ness to be an expensive inconvenience at the time.

[AristosQueue (NI)]

We do not want another debacle where we refactor the config API and break all of your applications. We only support version-over-version consistent behavior for the public API. If you want to use our private functionality, you need to make your own copy so that it continues to work in future LV versions. In 2009, we broke many applications when we refactored away a non-palette VI when we improved the config VI performance. We had documented for years that non-palette VIs are not guaranteed version-over-version, but people used them anyway, so we have since then been working hard to move such VIs to private scope. What is in the palettes is what we support. The rest is VIs that you can copy for your own use, but we cannot afford to have our hands tied by having to continually support every small subVI. Obviously we cannot retcon this for a lot of subVIs, but we are limiting access as much as possible, while still leaving such VIs not password protected so that you can copy them if desired.