Background
In my previous article, we discussed the creation of custom user settings in a Windows application without using the Browse choice illustrated in Figure 1.
In this article, we will discuss a practical example of creating custom user settings. The motivation for this article is to provide code that hopefully will help you visualize how you might proceed in developing your application to persist custom user settings.
Of course, there are other ways to persist custom user settings, but then you would miss out on the fun involved in using the System.Configuration.ApplicationSettingsBase
class. That class, to quote Microsoft, “Acts as a base class for deriving concrete wrapper classes to implement the application settings feature in Window Forms applications“.
Figure 1
Program Operational Overview
Let’s assume that a user wants us to make a change to some existing program. Specifically, the user wants to be able to enter dates and times for each week on a monthly basis so that she/he can specify when a report will be generated. Because some months can span up to six weeks, she/he wants to be able to configure up to six weeks. Fast forwarding to the finished program, let’s see how it works from the user‘s perspective.
When the user clicks the button in the window shown in Figure 2, the window in Figure 3 is displayed.
Figure 2
Figure 3
As you can see in Figure 3, nothing is configured. The only control that is enabled, besides the buttons at the bottom of the window, is the checkbox
for “Week 1“.
As the user progressively clicks the first five ”Week“ checkboxes, each row is enabled. Assuming the user entered information in each of those first five rows, she/he sees what is shown in Figure 4.
Figure 4
At this point, the user must click “Remember Setting“ to save her/his settings. The next time the user opens the WeeklySchedule window, she/he will see her/his previous settings.
Program Design
There is a state class for each type of control, where each of the classes inherits from the Week
class. Those classes are as follows:
CheckBoxControlItem
(inherits from Week
) DateTimePickerControlItem
(inherits from Week
) MaskedTextBoxControlItem
(inherits from Week
)
If you look at Figure 4 and do the math, you need to maintain thirty (30) objects as follows:
- Six (6)
CheckBoxControlState
objects - Twelve (12)
DateTimePickerControlState
objects - Twelve (12)
MaskedTextBoxControlState
objects
The thirty (30) objects are going to be placed inside a System.Collections.Generic.SortedList
that is defined as follows:
System.Collections.Generic.SortedList<string, Week>
The string argument, a key, will be the name of the control, while the Week
argument will be one of the following types of objects:
CheckBoxControlItem
(inherits from Week
) DateTimePickerControlItem
(inherits from Week
) MaskedTextBoxControlItem
(inherits from Week
)
The System.Collections.Generic.SortedList<string, Week>
object, along with its internal objects, is going to be persisted to disk when the Save
method (as seen within the code you can download) is called. The saving and restoring of our objects is all made possible because our WeekSettings
class inherits ApplicationSettingsBase
. The WeekSettings
class is show below, and the Save
method we just spoke about is a member of the ApplicationSettingsBase
class.
internal sealed class WeekSettings : ApplicationSettingsBase
{
[UserScopedSetting()]
[SettingsSerializeAs(System.Configuration.SettingsSerializeAs.Binary)]
[DefaultSettingValue("")]
public System.Collections.Generic.SortedList<string, Week> WeekSettingsList
{
get
{
return ((System.Collections.Generic.SortedList<string, Week>)
this["WeekSettingsList"]);
}
set
{
this["WeekSettingsList"] =
(System.Collections.Generic.SortedList<string, Week>)value;
}
}
}
History
- 9th September, 2008: Initial post
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.