Put the AppData.xml in the bin/debug and/or bin/release of the demo application project in order to run the demo application with an already created List of employees.
Whenever I make a Windows desktop application, I always need to save some of the data objects and variables used by the application in order to keep them persistent between sessions. The type of data that needs to be saved can usually be divided into 3 categories:
- Data that the application works with, which is dynamic by nature. The datatype is known at compile time but the number and content is not. This can for example be lists with objects - The minimal example list of employees in the demo project for example, a list of directories to watch for changes in or a dynamic list for an editable combobox to just mention some. For larger amounts of data, a database is more appropriate but there are several needs for smaller amounts of dynamic data in a normal application. Data that is loaded, maintained and then saved if changed without any fancy crossindexing or need for multi field sorting or searching.
- Configuration settings, preferences, properties and options that change or configure different aspects and operating modes of the application. This can for instance be a language setting, a difficulty setting, default paths, limits and which COM port to use. These are settings that normally are changed or set by the user with well defined interfaces, an options dialog for example, and then left alone for the majority of the application run time. Many times it is also critical for the use of the application that these settings don't change once they are set. The settings are normally loaded from file at application start and then saved back to file only when they are changed by the user.
- Background persistent variables that are entirely maintained by the application, indirectly changed by the user or the state of the application. This could be position, size and state of forms, dialogs or controls, counters and last used files to mention some. These variables and settings normally change frequently during the lifetime of the application but are only saved back to file when the application is closed. They are normally not critical for the way the application works. If lost, default values for the settings and variables can be used.
The classes in this library, called
RJConfig, handles all 3 categories above. In addition to that, it also has the following features:
- Data is stored in XML files.
- Data is organized in a 3 level hierarchy in the XML file. Sections contain Items which in turn contain Variables and their values. The section represents an area of the application, the item represents a sub area or an object and the variable is the setting, property, application variable or a member of an object.
- The properties and application variables (cat. 2 and 3 above) are declared and defined as member variables in the class it is used. The declaration contains the link to the file, the type of the variable, the location in the file hierarchy and a default value which is used if the variable doesn't already exist in the file or the file doesn't exist at all. Other information, depending on the type of the value, limits for example, can also be specified here.
- A value of a variable (the type of the variable) is defined with a class, making it easy to add new types. Even complex types.
- The link to a specific file, which is an instance of a
Configclass, is accessed through
staticmembers and standardized names. The name represents a
Configobject and its associated file. The filename is not used directly which, together with the fact that variables are declared where they are used, makes the design very "object oriented friendly". The class that uses the
Configobject doesn't have to know the filename, it only needs to know if the data is to be stored as an application property, a persistent variable or any other predefined, named type.
- More than one instance of a property or application variable can share the same value in the file. Just declare the application member variable with the same link to the file. When one instance changes the value, events can be raised to inform the other instances that a change has taken place. This mechanism can be used as a means of communication between classes.
- The associated XML file for a
Configobject can be monitored for changes made by external or internal sources. Whenever the file has been modified, events can be raised for the Section, Item or the single Variable that has been changed. This is useful for application properties or dynamic application data which allows other applications to change the mode of this application, at runtime. This can also be used to share the settings for several instances of one application running simultaneously. Change the setting in one instance and it will immediately be reflected in the other instances.
This library has evolved in several generations and is originally based on code written for MFC, C++ applications under Visual Studio 6 which I also released as a CodeProject article named Non volatile variables and configuration settings for MFC applications. Since then it has been totally remade for .NET with C# and has had a lot of new features added.
Using the Code
There are two main classes in the library. The first is the
FileConfig and the other is the