The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
App option specific stuff locally on the machine of the client. If there is a server everything else goes there into a database. Else I use depending on the amount of data a SQLite DB or XML/CSV files located in the AppData for everything.
For more complex data I try to stick to DB-like data, with SqlCE files or XML if I want human readable.
I also have a encryption class which has a file option for more secure data - but the data I serialise to that is normally XML.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
Back when I was a teenager, I thought saving UI State was all the rage but I soon gave it up. The massive amount of code required to store and manage it and make it all perfect just wasn't worth it. Heck, even today, I have a problem when I load firefox at home. You see I have a laptop hooked up to another monitor. However, that monitor is also wired to another machine. When the other machine is on, Windows on the laptop works fine but when I open something that was previously opened on the second monitor guess where it opens?
If Windows and Firefox can't manage to get UI saving settings right why even bother? Plus, if you make an infinitely configurable UI, power users will complain that they can't configure X and that is so obvious or worse an upgrade will wipe their settings and lose you a customer.
So, long story short, only save the bare essentials that make the app usable. The rest, don't make configurable unless they ask.
IMHO, this is a generic problem: i.e. restoring potentially invalid state. Whenever I restore state (almost always from an editable XML file), my code validates and auto-corrects the data being read. Other examples of this are selecting a tree node that may no longer exist, etc. The bottom line is, it's the developer's responsibility to handle all possible use cases.
All this takes additional work and time. And your users will love you for it.
I have been a developer for many years now,
and I support this message to the fullest.
So should YOU!
Seriously, settings are such a hassle.
The 'Appconfig' likes to forget them.
If you roll your own you have to be backward compatible.
Even VS has a 'reset to defaults button' for the interface because
it can get stuck in a bad layout you can not manually correct anymore.
If you provide too many options your application becomes 'too difficult'
Fortunately I was able to convince my coworkers of this.
Our application remembers the sizes of the screens,
when a screen is shown, it checks if the position is a valid
desktop position (making multi-monitor compatible even if you remove a monitor).
Whenever a customer ask for more setting, we say:
Tell us exactly what settings you want.
For which screens?
How should remember them?
Is it ok to break it with future changes.
But before you do this, remember that each setting cost 1 hour to develop,
1 hour to deploy, 1 hour to test.
Plus the square root (in hours) of all settings combined for additional testing where settings may interfere with each other.
Then multiply that with out hourly wage and ask yourself this question:
"Do you really want that setting?"
Maybe, one day, one of our clients will say yes...
Then we'll slap them with a 200% 'we really do not want to do this' bonus fee.
Yes, get's used from time to time; there's a wizard integrated into the IDE to manipulate the settings-file, it's defaults, and one can very easily bind to a property and forget about it.
Marc Clifton wrote:
if you develop client/server apps, if you store your app's state information locally or in a database so that your user can use any client machine and the UI is configured to their preferences ?
The apps state-information is not stored; only preferences, on user and application-scope (local and global). I've tried to save the complete state once (including undo/redo stack) and have the app restore to that state - it just confuses the users.
Marc Clifton wrote:
And yes, I'm talking about UI things, such as last window size and location
Hence the difference between "local" and "global" user-settings. Some things roam, others don't. The form-size doesn't roam, since my monitors have different sizes at different work-locations.
Marc Clifton wrote:
Same with, say, a tree control - what nodes were expanded and what nodes weren't?
No, not ever. How often do you need to be at that exact place in the tree? If very often, make a shortcut for the user. The reasoning is simlpe; you don't want to wait until the "Windows Explorer" loaded the entire tree, if you can simply click a hyperlink.
Marc Clifton wrote:
Plus things like "exit without asking" info, and so forth.
The question does not even exist. There's only a warning if something is dirty, but I'm not going to ask the user whether he knows what he/she is doing on every action.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
I typically save a file in the working directory, which allows the user to set up different shortcuts with different preferences if they want, and it makes the app portable as nothing is stored in system folders (or the registry etc) so you can put it on a USB stick. I put default configuration settings into the app as a resource so I can use the same reader to load it.
My application is a bit different. We run a printing press and related equipment. In that case, there aren't any 'user-specific' data to be persisted. At one time we would have used HKEY_LOCAL_MACHINE in the registry and called it a day, or stored a file with our application. Under Win7, none of that works. Our current solution is a group of XML files stored in the folder returned by SHGetKnownFolderPath(FOLDERID_ProgramData)[^].
I keep waiting for some moron to suggest we store settings data in the 'cloud' even though our machines never have an Internet connection...
It depends. In some applications it makes sense to use an XML file; in others, I use the registry; in others a database. In terms of what to save there: again, that depends on the applications. In some applications, form state is an integral part of how a document is displayed; in others it's unimportant. The same is true of behavioural settings. For Client/Server stuff, there usually ends up being a mix of techniques: things you want to persist across multiple installations of a product (by user) get stored in the database; stuff which has more to do with how the application looks on the screen of a specific machine get stored in the registry. I think it's all about common sense -- ask yourself questions like, "How annoying would it be if [this setting] did[n't] persist across different installation instances?".
I was asked this question at work. My first thought? How the hell do I know? I can't be done just like that. I would require to rewrite whole application. How much time it takes to make application for medium-sized company? 2? 5? After 10 it usually still under work and people are thinking about rewrite it in some other/better technology.
Worse is that I don't even know what is doing. There are now complete documentation, I saw it once and I don't have complete access to code. So how much time it would take? To hell with that. Whatever I will say it will be wrong anyway; nobody can predict that.
Give me 5 people and 2 years, I could care to try.
No more Mister Nice Guy... >: |
Last Visit: 31-Dec-99 18:00 Last Update: 22-Sep-17 22:04