RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Exploring Secrets of Persistent Application Settings

The .NET framework makes it easier than ever to create application settings and bind them to controls, but you need to know a few secrets to go beyond basic string settings and avoid problems.

he MSDN documentation includes a lot of material on persisting application settings in a Windows application (see Application Settings for Windows Forms ). But like much documentation, it's primarily a reference rather than a practical implementation guide, giving the complex and intricate usage details of settings without giving a clear and concise discussion of typical simple uses—exactly what a large number of users will be interested in. This article attempts to provide some tips on implementation.

You generally implement application settings because you want your program to remember changes users made, such as setting toolbar visibility, tracking menu checkboxes, maintaining split-window positions, or storing recent selections from an options dialog. Ideally, you'd want to store such settings simply and easily while writing minimal custom code. It's best to start with the basics. Here's the scoop in a nutshell.

Solution: Simple Uses of Settings
You create settings from the Settings tab of your project properties. As shown in the illustration, open the project Properties from the Solutions Explorer (or from the Project menu), then open the Settings pane, resulting in a table of settings in the middle pane. The table defaults to a single entry named "Setting" of type string with user scope, as shown in Figure 1.

Figure 1: Application Settings: You can enter or alter application settings from the Settings tab of your project Properties dialog.
After creating a setting, you can bind it to a Form control property using the "ApplicationSettings" section in the Form's properties pane. Alternatively, you can create and bind it in one step using the "ApplicationSettings" section in the project properties pane. You'll see this technique later when I discuss binding.

The property binding provides two-way automatic updates; that is, when the settings are loaded during startup the framework updates the control properties bound to them. Similarly, when the control properties change, the settings are updated, making the binding two-way. Before discussing binding though, consider the basics of settings first.

By walking through the process of adding a few settings you'll see how easy it is to connect settings to a Windows Form program.

Figure 2: Sample Settings: The figure shows the AppSettings editor with four settings of varying types defined.
Figure 2 shows four settings—two strings, one simple object (DateTime), and one Collection object (ArrayList). The Name value may of course be any descriptive term you care to use; that is how you will reference it in your program. The Type value may be any type of object that can be serialized as text, because the settings are stored in an XML format. The Scope may be either User or Application; Figure 2 shows string settings with each scope. You should think of Application-scoped settings as permanent, read-only, and global to all users. In contrast, User-scoped settings are modifiable values local to each user. The value field then, is the one-and-only value that an application-scoped setting will ever have. For a user-scoped setting, however, it is merely an initial or default value that may or may not change during a given invocation of the program. Once changed, a user-scoped setting may or may not retain that change for subsequent invocations, depending upon how you decide to treat it in your code.

So in Figure 2, the sample application has initial values for the strings but the more complicated objects are left as empty or null values. The application will initialize those in program code, although you could initialize them here. This is in fact a whiz-bang feature of Visual Studio. Clicking in the value field brings up an appropriate designer wizard for the specific data type. If you click on the LastRunTime value field, for example, you'll see the designer wizard shown in Figure 3.

Figure 3. DateTime Designer Editor: Visual Studio uses a Calendar editor to edit System.DateTime settings values.
Figure 4. ArrayList Designer Editor: Visual Studio uses the Object Collection Editor for ArrayList settings.
And clicking on the value field for ItemList yields the wizard in Figure 4.

For now, just leave both the LastRunTime and ItemList values blank; the application will populate them during execution.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date