The previous post, Exploring the TypingBuddy Application (Part 5), describes the technique for displaying messages of various types. A user can choose to use the default message or provide any of a number of randomly selected custom messages. This post assumes that the user has chosen the custom message route. Of course, that means having a database of messages to choose from. The act of adding and editing messages requires a special form, one that contains all of the fields required to perform these two tasks. The TypingBuddy application relies on frmAddEdit to perform this task. You saw this form described in the Exploring the TypingBuddy Application (Part 3) post. As described by its name, this is a dual use form that allows for either adding or editing message records to the XML file that contains the user’s data for this application.
A developer has a number of techniques available to create forms used for multiple purposes. In this case, the caller exercises control over public members of frmAddEdit to modify its behavior. This approach is actually the easiest way to do things. In order to make configuration easier, frmAddEdit defines three special properties:
These properties contain the message database, the selected record within that database, and a simple Boolean value that determines whether the form is in adding or editing mode. Because this form is created with flexibility in mind, you could probably add other properties to better control precisely how the form appears. However, you don’t require the level of flexibility described for frmMessage, so the use of multiple constructors (as in that case) is unnecessary.
The task of configuring the form falls to the frmAddEdit_Load() event handler. There are actually two levels of configuration required—the appearance of the user interface and the data shown within the form. The appearance is handled by the caller at the time the form is created, before it gets displayed. The data is configured as shown here:
When the form is in adding mode, the frmAddEdit_Load() event handler only has to add the list of available sounds to cbSound, and then select one of the items on the list. Because the form is already configured for adding mode, you don’t need to do anything to the user interface.
In editing mode, the frmAddEdit_Load() event handler must perform some additional tasks. It begins by configuring all of the common message data on the form. Then, if the UseDates property is checked, the event handler must also configure the starting and ending date values.
Handling the use of dates is an important consideration. You don’t want to set any dates unless the user says to use dates. Consequently, the application also requires the chkDateSpecific_CheckedChanged() event handler shown here.
This event handler enables or disables the date fields as needed. Notice that the date fields are always enabled and disabled as a pair. The user must set both a starting and ending date in order for the date system to work properly.
The most complex piece of code for this part of the example appears in the btnAdd_Click() event handler. This code must incorporate a number of safety check to ensure the user doesn’t enter an invalid record into the database. In addition, the code must ensure that dates are only recorded when the user wants to employ dates as a filtering mechanism as shown here.
As a minimum, a message must include a title and some message text. If the user doesn’t include any other information, the application will either rely on defaults or not provide that information as part of the output. Consequently, txtTitle.Text and txtMessageText.Text are the only two required entries. If the user doesn’t provide these two entries, the application displays an error message and exits.
When the required input is correct, the code moves on to creating a temporary array to hold the updated data. This is a safety feature to ensure that the entire transaction takes place before being made permanent. If the application should suddenly fail between steps, the initial array will still hold valid information.
In editing mode, the btnAdd_Click() event handler begins by copying all of the records from MessageList (the permanent array) to Temp (the temporary array). It then changes each of the required values in Temp. Notice how the code handles dates. Again, it only saves dates when the user wants to use dates as a filtering mechanism. The final step is to make the change permanent by copying Temp to MessageList.
In adding mode, the application can’t assume there are any existing records. As a result, the first check is to determine whether this is a new list of messages or an addition to an existing list. When it’s an addition, the code simply adds a new entry to Temp and copies the required records from MessageList to Temp. However, when this is a new list, the code simply creates a single entry array in Temp. At this point, the process is much like editing an entry. The new values are added to the empty array element and then Temp is copied to MessageList.
Next week we’ll move one level up in the form hierarchy and examine frmMessages. In the meantime, let me know if you have any questions about this part of the example at John@JohnMuellerBooks.com. You can see the next part of this series at Exploring the TypingBuddy Application (Part 7).