>>>OTOH, my bet is that most users wouldn't know how to open it. They'd doubleclick it and it would open in IE, readonly :).
>>>
>>>Ini file may be better. Even if one line is screwed up, the rest is still usable. And you can supply defaults within the same line where you read the values.
>>
>>I agree that INI is more "secure" than XML from the stand point of messing it up. But INI is so 90s <g>.
>
>Who cares. It ain't broken, and I won't try to fix it. And it's blazingly fast, while xml parsing grows squarely (i.e. the time to process grows with the square of its length, because it's read sequentially). Ini is also read sequentially, but it's much smaller and doesn't have all the fluff.
>
>>But I like Tamar's suggestion of checking who changed the file. She also suggested to store the "base" XML file to the .EXE which won't be practical (since each customer has a different settings). But I will see if I can store the "last" version of the XML file into some "hidden" place and being able to restore it, in case checksum does not match (as she suggested). Or if user corrupts the file.
>
>The checksum also won't match if a user made a legitimate and regular change, for example changing a phone number or fixing a typo in some name.

My suggestion of a checksum was to keep users changing the settings only through the application. I like Dmitry's idea of storing the last known good version, so that you can go back to something the user created rather than the raw version that comes with the app.

Dmitry--if you're going to INI or XML, how about storing the last known good in a memo field of a table?

Tamar