Quantcast
Channel: John's Random Thoughts and Discussions » John's Random Thoughts and Discussions |
Viewing all articles
Browse latest Browse all 10

Exploring the TimeCheck Application (Part 14)

$
0
0

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.

 


Viewing all articles
Browse latest Browse all 10

Latest Images

Trending Articles





Latest Images