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:
- 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:
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:
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.
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.