Click here to Skip to main content
13,298,551 members (74,234 online)
Click here to Skip to main content
Add your own
alternative version


53 bookmarked
Posted 14 Sep 2002

Save Application Settings to XML

, 16 Sep 2002
Rate this:
Please Sign up or sign in to vote.
An easy to use class that reads, writes and deletes app settings to an XML file.


Why another application settings XML class?

  1. Because INI files are so Win16.
  2. The registry is too big and you could really screw something up messing with it.
  3. XML seems to be the popular choice.

See Read and Write application parameters in XML for better reasons.

This class should make it easy to read, write and delete application settings to an XML file using the familiar registry key/value nomenclature (ex. "MyApp\Appearance\Font\Face"). If it doesn't make it easy, um... I didn't write it.

The CXMLSettings Class

To use the class, there are only 6 methods you will need to worry about.

  • void SetSettingsFile(CString cstrFile)
    • Sets the path and filename for the XML settings file.
  • long GetSettingLong(CString cstrBaseKeyName, CString cstrValueName, 
    long lDefaultValue)
    • Returns a long value extracted from the settings file given a key and value name.
  • long SetSettingLong(CString cstrBaseKeyName, CString cstrValueName, 
    long lValue)
    • Sets a long value in the settings file given a key and value name.
  • CString GetSettingString(CString cstrBaseKeyName, CString 
    cstrValueName, CString cstrDefaultValue)
    • Returns a string value extracted from the settings file given a key and value name.
  • long SetSettingString(CString cstrBaseKeyName, CString cstrValueName, 
    CString cstrValue)
    • Sets a string value in the settings file given a key and value name.
  • BOOL DeleteSetting(CString cstrBaseKeyName, CString 
    • Deletes a key or value from the settings file given a key and value name.

Other methods in the class parse key/value "chains", and load, save, and traverse the settings file.

How to Use It

  1. Call SetSettingsFile to tell the class where the XML file will be saved.
  2. Call one of the Get, Set or Delete methods using the registry-like nomenclature for the first parameter (ex. "MyApp\Appearance\Font"). A default value may also be sent as the last parameter to the Get methods.
  3. The DeleteSetting method can be used to delete an entire key or a value under a key.

That's it!

If the XML file does not exist or if a key/value does not exist, the Set methods will create it and the Get methods will return the default value.


The class and the demo app use MFC and MSXML 4.0. Please let me know if you find any bugs are would like to see improvements.

Other articles lie this one:


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Jason Henderson
United States United States
I have been a professional developer since 1996. I live in the middle of no where in Illinois, USA. I am married and have four children.

You may also be interested in...


Comments and Discussions

GeneralRe: XML vs. Registry Pin
Tim Smith16-Sep-02 5:02
memberTim Smith16-Sep-02 5:02 
GeneralRe: XML vs. Registry Pin
Jason Henderson16-Sep-02 5:06
memberJason Henderson16-Sep-02 5:06 
GeneralRe: XML vs. Registry Pin
Paul A. Howes16-Sep-02 7:57
memberPaul A. Howes16-Sep-02 7:57 
GeneralRe: XML vs. Registry Pin
Jason Henderson16-Sep-02 9:38
memberJason Henderson16-Sep-02 9:38 
GeneralRe: XML vs. Registry Pin
Anonymous16-Sep-02 10:56
sussAnonymous16-Sep-02 10:56 
GeneralRe: XML vs. Registry Pin
Houdini17-Sep-02 6:16
memberHoudini17-Sep-02 6:16 
GeneralRe: XML vs. Registry Pin
Paul A. Howes17-Sep-02 7:43
memberPaul A. Howes17-Sep-02 7:43 
GeneralRe: XML vs. Registry Pin
Houdini17-Sep-02 8:39
memberHoudini17-Sep-02 8:39 
First off, I'd like to commend you on your well thought out reply. You made some very good points and kept and open mind. I guess I'm just not used to that when dealing with message boards Wink | ;) .

The XML itself is portable, but the methods used to access it are not. You may argue that SAX, SAX2, and DOM are standard interfaces, but every platform seems to have a different implementation. If you want to write your own parser, that's fine, but there are better uses of a developer's time than recoding something that already exists. You may even want to drag a third-party library along, such as Xerces, but that becomes yet-another dependency to deal with when you distribute your application. However, I do not disagree with you: I have been looking into some cross platform development (Windows and FreeBSD w/ KDE) and encountered the same problem.

True, it's not a perfect solution. However, if you were going to port it to a different operating system, you'd need to make more changes going from the registry to XML than you would plugging in a 3rd party parser.

Of course, it may be even easier to just create your own portable, and simple, text file format and reader/writer.

I may be missing something here, but I have rarely run into cases where hacking the registry fixed my application. I try to follow a simple rule: Every registry setting has a corresponding GUI setting.

That's a very good rule to follow, and something I admit I don't always follow myself =). Still there may be interal data you don't see a need to, or would rather not, expose to the user. Such as last known positions of windows, a MRU list (you may not want MFC to handle the MRU if you have portability in mind, and other libraries may not even support this internally (Borland, WTL, Win32, QT, etc)).

If your deinstallation program doesn't remove settings that were created by either the installation program or the application itself, then the deinstaller was poorly written. I would consider that a defect. Don't take that statement personally; I am not directing it at you. I have had the same experience with many applications.

Yes, in this case the deinstaller was poorly written and should be considered a defect. Still, there are many programs that have this bug, and there will always be some that will, unless Microsoft decides to automatically clean an applications registry folder upon uninstall.

It's funny -- I have never had a corrupted registry that I am aware of, and yet I hear people talk about this all the time. I would be curious to know how you define "corruption", and how it actually occured.

Ok, ok, I've never actually had my registry "corrupted" but I have experienced invalid entries which I could never track down that caused me to get numerous error messages upon starting Windows. And since Windows booted successfully the backup registry files got overwritten with the "invalid" ones. In the end I decided to re-install a new Windows over my old one, which of course meant I needed to re-install all my applications since they kept information in the registry.

Still, I would think that corrupted registries are fairly uncommon, but nonetheless it is another potential problem when applications access it constantly.

- Houdini
GeneralWhy XML Pin
Chris Holt15-Sep-02 15:06
sussChris Holt15-Sep-02 15:06 
GeneralRe: Why XML Pin
Maximilien15-Sep-02 15:17
memberMaximilien15-Sep-02 15:17 
GeneralRe: Why XML Pin
Tim Kosse15-Sep-02 21:41
memberTim Kosse15-Sep-02 21:41 
GeneralRe: Why XML Pin
mstephens16-Sep-02 0:31
membermstephens16-Sep-02 0:31 
GeneralRe: Why XML Pin
Jiminy15-Sep-02 18:12
memberJiminy15-Sep-02 18:12 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.171207.1 | Last Updated 17 Sep 2002
Article Copyright 2002 by Jason Henderson
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid