Home > View Post

Easy Settings in WinForms

It's often nice to garnish your application with a liberal sprinkling of settings that are saved to disk so the user doesn't have to reenter their options next time. You can take this even further and remember general things about the application, such as the location of a window, for example.

In Visual Studio 2005 this is incredibly easy with the introduction of the Application Settings feature.

Take our first example, where we want to remember the location of a window next time an application starts. Just click on your form and head for the ApplicationSettings item in the properties window.

Application Settings in Visual Studio properties window

This allows you to directly databind properties of the Form to some settings. Since we want to set the windows Location we could use the shortcut provided but we're not going to cheat here. Oh no. Click on the PropertyBinding ellipsis (...) to launch the dialog shown below.

A list of all properties that can be automatically binded

This dialog shows a list of all the properties of the Form dialog that can be automatically bound to settings. Click the dropdown next to the Location property and you'll see a list of suitable settings or, because we haven't created any yet, an empty list like this.

Available settings (Empty) and a link to (New...)

Fortuitously though, we can create a new application setting right here by clicking on the New... link.

New Application Setting Dialog

Each Application Setting has a number of properties itself. You can specify the Default Value for the location when no setting is found (note how it has recognised that the property is of type Point). Your setting also needs a name; we've called ours "MainWindowLocation". Finally, there's a scope which can be either Application or User.

User settings are persisted for each windows user independently (because Aunt Bettie likes her windows in the bottom corner, whereas uncle Derek likes to move his about a lot). Application scoped settings will be shared by all users on that machine (so uncle Derek will get his window wherever the last user left them, even if that user was aunt Bettie).

In most instances, you probably want to go for a user scoped setting, which is the default.

The Settings.settings file under the Properties folder

If you look inside the Properties folder of your project you'll see the Settings.settings file which is designed for storing such settings, and this is exactly where your new settings is stored. Double click the file and you should see your new setting right there.

Your new setting in the .settings file

You can add your own settings for whatever you like right here.

Cool, what next?

The only thing left for you to do is decide when to save the settings to disk. Traditionally this is done when the application is closing, in the FormClosed event.

private void Form1_FormClosed(object sender, FormClosedEventArgs e)

And I think this is fine for fairly trivial things like window location. However, if your settings contain something that the user has purposefully configured (maybe a color scheme or a connection string) I feel strongly that these should be persisted right away. That is, when the user enters the data or clicks OK on your settings dialog. There's nothing worse than entering a load of settings and have the application crash on you so the normal FormClosed event isn't raised. Arrggh!!

Look out

I did spot one interesting gotcha with these automagically configured ApplicationSettings too. The implementation of the Settings data is a static class (as you can see in the FormClosed event handler above) which means they are shared across an entire AppDomain. What if you have two instances of the same Form class active and visible at the same time? Well, as you move windowA it will write back to the static settings repository. This change is picked up and propagated to any listeners, one of which will be windowB.

The effect? Your two windows will stack exactly on top of each other and as you move one, the other will move right underneath it!

What no Size?

The two properties of Form that I imagine most people might want to use in this way are Location and Size. However, you won't see the Size property in the dialog we shown above because it is marked as DesignerSerialiationVisibility.Hidden.

Fortunately, a guy called Raghavendra Prabhu has a great post that solves both these problems: Saving out a Form's Size and Location using the Application Settings feature.

However, be sure to read Raymond Chen's post about the pitfalls of using settings in this way: A subtlety in restoring previous window position.

The last post may well make you decide that this isn't something you want to be doing at all! Which is fair enough, but don't throw the ApplicationSettings baby out with the proverbial bath water - it can be extremely useful.

Tags: WinForms.NET

Josh Post By Josh Twist
2:24 AM
25 Jan 2007

» Next Post: Scott Guthrie hits the Sweetspot again
« Previous Post: Modeless Dialogs in WinForms

Comments are closed for this post.

Posted by Arthur @ 25 Jan 2007 5:36 AM
Thanking your for a very insightfull article.

© 2005 - 2022 Josh Twist - All Rights Reserved.