Overload WriteProfileXXX/GetProfileXXX to store settings in XML instead of registry?

[Dan203]

Does anyone know of an MFC class that overloads the CWinApp WriteProfileXXX/GetProfileXXX functions so that settings are stored in XML rather then the registry? I know there is a way to use an INI instead, but that seems like it's depreciated. From what I've read .NET has a way to write settings to XML, but I don't see anything similar for MFC.

If there isn't a ready made class out there I'll just do it myself, but I was hoping to save myself the effort.

[VictorN]

What is the reason to NOT use the registry?

[Dan203]

Our program is a complex video editing/processing app with a TON of settings. When diagnosing an issue it's hard to tell if it's a bad setting or an actual bug causing the issue. Usually our first recommendation to a user when diagnosing an issue is to uninstall/reinstall, but a lot of them are reluctant to do that because it deletes all their settings. We also get a lot of requests to make the settings portable, so they can be copied to multiple machines. Storing the settings in an XML seems like it would solve both of those issues. We could have users "reset" their settings by simply renaming the XML file for testing and the users that want to copy settings could simply copy the XML between machines.

I actually recently added an import/export option for the second case, and it sort of helps the first case too as it allows users to back up their settings before uninstalling, but it's a bit more cumbersome.

Is there a reason why not to use XML instead of the registry? Is XML going to be significantly slower or more prone to error?

[VictorN]

...
Is there a reason why not to use XML instead of the registry? Is XML going to be significantly slower or more prone to error?

I may be wrong, but in my opinion, it's like reinventing the wheel...

[Dan203]

I may be wrong, but in my opinion, it's like reinventing the wheel...

Perhaps, but obviously I'm not the only one who wants this functionality as it appears to be pretty common for .NET applications to use XML files for settings rather then the registry.

If anyone knows of a class that already does this I'd love to get a link. If not I guess I'll roll my own and see how it goes.

[2kaud]

I know there is a way to use an INI instead, but that seems like it's depreciated

What's wrong with .ini files? The Write/GetPrivatexxx() API's haven't been depreciated and aren't going away any time soon - and if at some distant time in the future Microsoft decides to withdraw them, it's fairly easy to replicate them.

[Dan203]

What's wrong with .ini files? The Write/GetPrivatexxx() API's haven't been depreciated and aren't going away any time soon - and if at some distant time in the future Microsoft decides to withdraw them, it's fairly easy to replicate them.

INI files are harder to edit by hand and less structured. If I'm going to write a text file anyway XML just seems more modern and easier to read/edit if needed.

I'm a little concerned about the performance/memory hit though. I need to do some testing and see if it has a significant impact. If it does then I'll just have to guide customers to the import/export feature I already have.

[STLDude]

I have used TinyXML as my xml reader and writer. It does not have validation built in, but it's small, fast, fairly efficient and easy to add to your project.

I want to make couple comments regarding other bits of your post. You mention to prefer xml over ini. Over many years in my career, where editing xml files is fairly common, like in notepad type of the program is not that fun. xml files are very noisy and it's not obvious of data structure. This sentiment is not only mine, but many other colleges would agree with it.

ini files are easy to read and mostly to the point. And mostly user settings are key value pair, so ini lends well to it. If user ever wants to edit that file manually (like in notepad), then looking at the ini file would be easier over xml. Try to load fairly complex xml file into your windows notepad (no color syntax, 8 spaces per tab) and you will see that it's not easy to read. Now, try to add or change settings in it. xml is much less forgiving for typos, then ini for example.

Of course, it is your call, I just wanted to convey my and many other people experience with xml.

For the performance, I don't think it matters. It is not like you are going to be saving or loading hundreds of times per second setting file. You read it at startup once, cache the values and move on, and then save it when user changes the setting, or on exit the app.

[2kaud]

If I'm going to write a text file anyway XML just seems more modern and easier to read/edit if needed

I agree with STLDude in post #8. We've experimented with various methods and where use of the registry (which should be the first choice) is not considered appropriate then we think .ini files are the next best.

[Igor Vartanov]

I actually recently added an import/export option for the second case, and it sort of helps the first case too as it allows users to back up their settings before uninstalling, but it's a bit more cumbersome.

To make it less cumbersome, you may backup the settings on any settings change, as well as program start and shutdown.

Is there a reason why not to use XML instead of the registry? Is XML going to be significantly slower or more prone to error?

It's absolutely up to you. Storing settings in the registry is standard and recommended approach. The registry key is exportable/importable, and thus portable, yet again, absolutely (hint: reg.exe). So ultimately it's a matter of your personal preferences and skills.

[Dan203]

Yeah after thinking about this more I'm not sure the minor benefit this provides over the import/export we already have is really worth the effort. I added this to my ToDo list before we had the import/export, and back then it seemed much more important. But now the benefits over what we already have seem minimal. I was just tackling some stuff on my ToDo list yesterday and came across this which is what prompted this thread. I think I'm going to skip it for now.

As for XML vs INI... I've been writing HTML by hand since the mid 90s, so to me XML is second nature and seems completely intuitive. INI files seem unstructured to me. With XML you can structure the tags to match the structure of the settings screen (which has multiple tabs) so it seems more intuitive to edit by hand. That being said I seriously doubt many (any?) of our users would be editing this file by hand anyway. It's mainly going to be used for backup and support.

[Arjay]

Yeah after thinking about this more I'm not sure the minor benefit this provides over the import/export we already have is really worth the effort. I added this to my ToDo list before we had the import/export, and back then it seemed much more important. But now the benefits over what we already have seem minimal. I was just tackling some stuff on my ToDo list yesterday and came across this which is what prompted this thread. I think I'm going to skip it for now.

As for XML vs INI... I've been writing HTML by hand since the mid 90s, so to me XML is second nature and seems completely intuitive. INI files seem unstructured to me. With XML you can structure the tags to match the structure of the settings screen (which has multiple tabs) so it seems more intuitive to edit by hand. That being said I seriously doubt many (any?) of our users would be editing this file by hand anyway. It's mainly going to be used for backup and support.

Used to be that storing settings in the registry was the way to go. Now-a-days, not so much (even if MFC supports this approach).

Xml is perfectly valid (even JSON). Not that it is available, but in .Net there is an XmlSerializer class that allows you to read from xml and it turns it into a class instance (where xml elements and/or attributes become class properties). This is called deserialization and you can serialize also where a class instance is turned into xml. It's too bad this isn't available for native C++ because it's really slick.