Exploring the TimeCheck Application (Part 14)

Today we’ll wrap up the discussion about frmConfigure. If you remember from the Exploring the TimeCheck Application (Part 13) post, we’ve finished up the major configuration controls, but there are three areas that you still need to know about:

 

  • Constructors
  • Form Loading
  • Form Closing


All three of these elements appear in this post. Let’s begin with the constructors. The application can either create frmConfigure by defining a blank form or by passing information needed to populate the form with data. The following code shows both of the constructors needed to fulfill these tasks:

// Create a variable to hold the user data.
public UserSettings UserData;
 
// Create a variable to hold the group data.
public GroupSettings GroupData;
 
public frmConfigure()
{
   // Perform the default configuration.
   InitializeComponent();
 
   // Check for the user data.
   if (UserData == null)
 
      // Initialize the user data.
      UserData = new UserSettings();
 
   // Check for the group data.
   if (GroupData == null)
 
      // Initialize the group data.
      GroupData = new GroupSettings();
 
   // Fill the administrator provided task and project lists.
   FillLists();
}
 
public frmConfigure(UserSettings UserData, GroupSettings GroupData)
{
   // Perform the default configuration.
   InitializeComponent();
 
   // Check for the user data.
   if (UserData == null)
 
      // Initialize the user data.
      this.UserData = new UserSettings();
 
   // Otherwise, use the supplied settings.
   else
      this.UserData = UserData;
 
   // Check for the group data.
   if (GroupData == null)
 
      // Initialize the group data.
      this.GroupData = new GroupSettings();
 
   // Otherwise, use the supplied settings.
   else
      this.GroupData = GroupData;
 
   // Fill the administrator provided task and project lists.
   FillLists();
}

In both cases, the constructor must create the UserData and GroupData local variables that you’ve seen used for so many purposes in the application. When the caller supplies the required data, frmConfigure uses it. Otherwise, frmConfigure creates new, blank variables that the application can fill with data. No matter how the data are supplied, the constructors call FillLists() to fill the user interface with data so that the user can see the settings (if any).

The form isn’t completely populated with data, nor is it stable at this point. The application raises the FormLoad() event at some point, which calls this event handler:

private void frmConfigure_Load(object sender, EventArgs e)
{
   // When there is user data to use, display it.
   if (UserData != null)
   {
      // Configure the form fields.
      cbProjectName.SelectedText = UserData.DefaultProject;
      cbWorkType.SelectedText = UserData.DefaultTask;
      txtNetLocation.Text = UserData.NetworkPath;
      chkCustomProject.Checked = GroupData.CustomProject;
      chkCustomWork.Checked = GroupData.CustomTask;
   }
}

At this point, the form is ready for the user to interact with. We’ll be looking at some additional code later to handle the requirements for working with administrators, versus standard users. For now, just consider that the form is ready to use. The user does whatever he/she needs to do, and then clicks either Cancel or OK to close the form. Now, some actions automatically save data because you simply don’t want to take a chance that the user will close the form in some other way and lose settings. However, it’s important to save the data one last time when the user clicks OK to ensure absolutely every change appears on disk. That’s the purpose of the two event handlers shown here.

private void btnCancel_Click(object sender, EventArgs e)
{
   // Close this dialog box.
   Close();
}
 
private void btnOK_Click(object sender, EventArgs e)
{
   // Save the changes to the user data.
   if (cbProjectName.SelectedText != "")
      UserData.DefaultProject = cbProjectName.SelectedText;
   if (cbWorkType.SelectedText != "")
      UserData.DefaultTask = cbWorkType.SelectedText;
   UserData.NetworkPath = txtNetLocation.Text;
   UserSettings.SetUserSettings(UserData);
 
   // Save the changes to the group data.
   GroupData.CustomProject = chkCustomProject.Checked;
   GroupData.CustomTask = chkCustomWork.Checked;
   GroupData.ProjectList.Clear();
   foreach (String Item in lstStandardProjects.Items)
      GroupData.ProjectList.Add(new Project(Item));
   GroupData.TaskList.Clear();
   foreach (String Item in lstStandardTasks.Items)
      GroupData.TaskList.Add(new Task(Item));
   GroupSettings.SaveSettings(GroupData);
 
   // Close the dialog box.
   Close();
}

As you can see, clicking Cancel simply closes the form. However, when you click OK, the application saves the data as it appears on screen. This is important because it’s possible that things could have gotten out of sync as the user interacted with the form. The result of the btnOK_Click() event handler is that the data on disk appears precisely the same as the user saw it on screen.

At this point, you have a basic frmConfigure completed. The next post will focus on the code used to make frmMain work. In the meantime, let me know if you have any questions about any of the frmConfigure code at John@JohnMuellerBooks.com.

 

Author: John

John Mueller is a freelance author and technical editor. He has writing in his blood, having produced 99 books and over 600 articles to date. The topics range from networking to artificial intelligence and from database management to heads-down programming. Some of his current books include a Web security book, discussions of how to manage big data using data science, a Windows command -line reference, and a book that shows how to build your own custom PC. His technical editing skills have helped over more than 67 authors refine the content of their manuscripts. John has provided technical editing services to both Data Based Advisor and Coast Compute magazines. He has also contributed articles to magazines such as Software Quality Connection, DevSource, InformIT, SQL Server Professional, Visual C++ Developer, Hard Core Visual Basic, asp.netPRO, Software Test and Performance, and Visual Basic Developer. Be sure to read John’s blog at http://blog.johnmuellerbooks.com/. When John isn’t working at the computer, you can find him outside in the garden, cutting wood, or generally enjoying nature. John also likes making wine and knitting. When not occupied with anything else, he makes glycerin soap and candles, which comes in handy for gift baskets. You can reach John on the Internet at John@JohnMuellerBooks.com. John is also setting up a website at http://www.johnmuellerbooks.com/. Feel free to take a look and make suggestions on how he can improve it.