The previous post, Exploring the TimeCheck Application (Part 7), discussed the UserSettings class, which is used to store user settings to the local hard drive. One of the most important settings included in this class is NetworkPath, which points to the location of the group settings and time logs on the network. Using centralized storage makes it possible for an administrator to set the configuration of all systems on the network at once and to also get reports for the activities of all users, even when the target user is offline. Of course, you could always use a local drive for the NetworkPath when you’re the only one working with TimeCheck. No matter where you store the data, the next level of settings are the group settings used to control the overall functionality of the application. These group settings are the target of today’s and next week’s posts.
The first step in this process is to create some classes. The GroupSettings class contains the actual settings you work with. However, to ensure that you can define tasks (the kind of work the user performs) and projects (the client or area of the company that is the client for the work) as you see fit, you also need to create the Project and Task classes. You can create all three classes (GroupSettings, Project, and Task) using the techniques found in Exploring the TimeCheck Application (Part 7).
The Project class is quite simple in this example. All you really need is the name of the project as shown in the following listing.
Notice that this class is marked as [Serializable()], which is a requirement when working with XML storage files. An implementation for a larger organization could include additional information, such as the client contact information. The idea is to create properties that define what a project is to your organization. In my case, all I need is the project name.
The Task class for this example is similarly simple. All it contains is the name of a task that the user might perform, such as word processing or graphics. Here is the source code for this part of the example.
As with the Project class, you must mark the Task class as [Serializable()]. Even though my class contains only the name of the task, you could easily expand this class to include other information, such as a list of work groups that normally perform this task. The use of a class makes it possible to expand the definition of a task as needed to match the requirements of your organization.
In order to start coding the GroupSettings class, you must provide both file and XML support. You need to add the following using statements at the beginning of the file.
Look again at frmConfigure in Exploring the TimeCheck Application (Part 3). The top half of this form relies on the UserSettings class, while the bottom half relies on the GroupSettings class. There are four properties that support the four fields shown in the bottom of frmConfigure as shown here.
Notice that the CustomProject and CustomTask properties are simple Boolean values. They never require any error handling because the properties are set using a simple check on the form.
The ProjectList and TaskList properties are a List object of type Project and Task. Using generics solves some problems later in the application and makes the code easier to understand and work with. The example application uses the simplified property setup for these properties as well because the application never does anything with the strings except to display and store them. If the application had processed the strings in some way or the Project or Task classes were more complex, then the properties would have to include some sort of error trapping. Keep this in mind if you decide to enhance the example code in some way.
That’s it for this week. Next week you’ll see how to complete the GroupSettings class. Please let me know if you have any questions about this class or any other part of the TimeCheck application at John@JohnMuellerBooks.com.