Fed up with us pesky developers changing the preferences file all the time, so yours hasn't got the right things in?
Now, if you have debugging turned on, it'll compare your file with the distribution one when the host software is run and report the differences.
I know. Debug is one of the preferences... And, if you have it switched off it doesn't do the check as soon as you switch it on. But it does do it the next time you start the system.
A nice way around that is to have two preferences files - one comes with the distribution and is not supposed to be changed by the users - the other is created by the user and contains just the things he wishes to override from the distribution file.
ReplyDeleteThat allows the developers to add and subtract configuration and play around with the default values of things - without screwing up the things that the user set explicitly.
That's exactly how it works. The user's file is read first. If the system needs something that the user hasn't specified it looks in the distributed file. If the user's file doesn't exist at all, the distribution file is copied into it as a start.
ReplyDeleteMy addition compares the two and reports all differences or omissions in names.
No - you aren't doing what I'm suggesting. Copying the distribution file into the user file if it doesn't exist is your problem.
ReplyDeleteYou need to create an EMPTY file if the user file doesn't exist - and encourage your users to add just the entries for the things they need to change. That way a typical user file is almost empty - perhaps just a couple of lines where he needs to tweak things.
Then, (as a developer) you can change anything you like without worrying. Any user who hasn't expressed a preference by adding an entry into the user file will get your new defaults - old variables you don't need anymore will disappear and you can add new ones just as easily. All of this without overwriting the few things your end user needs to override.
The user can see at a glance what he's changed from the defaults - and if he causes problems by so doing, you can see at a glance what he messed up without having to email hundreds of lines of config file back and forth all the time.
Best of all, you don't need to do the "compare and report" thing - because the differences are already right there in his user file.
I've used this scheme in a dozen applications over the years - it's by far the cleanest.