Tag: .NET Framework

We’re finally down to the last baseline post for the GrabAPicture application, frmAddEdit, which is the chameleon form. The Exploring the GrabAPicture Application (Part 11) post describes how the frmConfigure code modifies the appearance of the code for this form so it can perform several tasks. At the center of this capability are several versions of the constructor that allow for different configuration techniques as shown in the following code.

As you can see, each of the constructors provides one more level of configuration. You might wonder why the application doesn’t simply use the most configurable of the four constructors, but this approach has some disadvantages.

• Using just a single, complex constructor makes the application inflexible.
• The developer would also need to provide the default values for title, button, and remote editing capability, even if these values didn’t change from the default dialog box.
• Adding this requirement would make the application more susceptible to errors.
• Using four different constructors also forces the developer to consider which entries actually do need to change. Giving someone the opportunity to think application design through is never a bad idea.

Notice that the fourth constructor contains special code for removing the browse button from view when working with a remote resource. The browse button wouldn’t do the user much good in this case and clicking it can only cause problems.

Using the custom constructors is really important in this case and makes the application much stronger. You can divide the rest of the code for this form into three areas:

• 
  Property creation and maintenance
• 
  Form loading
• 
  User controls

Most of the code for this form is straightforward, albeit a bit convoluted at time due to the form’s multipurpose nature. The following sections describe each of the coding areas.

Property Creation and Maintenance

This form is used in a number of ways, so it’s important that the application be able to track the form’s current state. Otherwise, the application could make an assumption about the form content that isn’t correct. The best way to provide state information outside of the form is to use properties. Relying on properties makes it possible to monitor and control interaction with form state information in a controlled way. The application uses the properties shown here.

The properties are pretty straightforward. They serve the following purposes:

• 
  Resources: Defines a local URI.
• 
  RemoteSources: Defines a remote URI.
• 
  IsRemote: A read-only property that the application can use to determine whether to access the Resources or RemoteSources property for the current URI.
• IsEdit: Controls whether the dialog box provides an adding or editing appearance. The adding dialog box is blank, while the editing dialog box contains the current local or remote record information.
• RecordNumber: Contains the record number of the current local or remote source.

Form Loading

Form loading is important because the code in this area controls the initial appearance of the dialog box. A form used for adding a new record, whether local or remote, is always blank, so it doesn’t require any custom configuration. However, if the form is used to edit a current record, the form loading code must detect whether the form is editing a local or remote resource. In addition to URI differences, local resources have an additional button available for browsing the local hard drive. The following code shows how form loading works.

As you can see, the first thing the code detect is whether the form is using for adding. If it is, then the application doesn’t do any configuration.

When the dialog box is used for editing, the application checks the status of _IsRemote to determine how to configure the dialog box. The code obtains the correct record and then displays the information on screen.

User Controls

There are three user controls, but you only need to provide code for two of them (btnCancel provides the default action when clicked). The Add/Edit button (btnAddEdit) is always visible. The relies on it to make any changes permanent. The browse button (btnGetResource) is only available when working with a local resource. The user relies on this button to locate resources on the local hard drive. The following code shows how these buttons work.

Let’s discuss the simple button first. When the user clicks the browse button, the application displays an OpenFileDialog control, OFD. If the user selects a file and clicks OK, the code places the name of the file into txtLocation.Text. Theoretically, a little customization would make this dialog box friendlier, but it works well as presented.

The btnAddEdit_Click() event handler is a little more complex. It actually performs one of four actions depending on the dialog box options.

• Edit/Remote: The code changes the record information found in _RemoteSources for the current record pointed at by _RecordNumber.
• Edit/Local: The code changes the record information found in _Resources for the current record pointed at by _RecordNumber.
• Add/Remote: The code either creates a new _RemoteSources array or adds an element to the existing _RemoteSources array. In both cases, the code adds the new record to the end of the array. Note that because the array is zero-based, you must subtract 1 from the array length in order to find the last record of the new array.
• Add/Local: The
  code either creates a new _Resources array or adds an element to
  the existing _Resources array. In both cases, the code adds the new
  record to the end of the array.

Well, now you have the full story on the base application—the application I started with. The next post will discuss some of the additions we’ll pursue in the new year. For now, please keep those comments coming. Let me know if you have any questions at all about this form at [email protected].

The previous post in this series, Exploring the GrabAPicture Application (Part 10), discussed frmMain, which allows the user to perform application configuration and manually configure the Desktop wallpaper. The focus of this application, however, is automated configuration, which is the purview of frmConfigure—the topic of discussion today. The user relies on frmConfigure to add, edit, delete, and select either local or remote graphic sources for the Desktop wallpaper as shown here.

There are really two sets of four buttons here: the local set and the remote set. Each set performs the same sets of tasks with a different part of the same XML database. The information about this database appears in previous posts, but the main post of concern is Exploring the GrabAPicture Application (Part 8). When adding or editing a database element, the user sees a form similar to the one shown here:

Even though frmConfigure looks a little complex, there are really only three groups of tasks to perform:

• Load the current database
• Manage local database resources
• Manage remote database resources

Load the Current Database

The first task is to load the current database. In this case, the application creates and configures a global variable that provides access to the preconfigured wallpaper choices as shown here.

The global variable, CurrentSettings, is of type GrabAPictureSettings. The application begins trying to fill CurrentSettings by calling GrabAPictureSettings.LoadSettings(). When this is the first application use and the user hasn’t added any wallpaper yet, the result of this call is that CurrentSettings equals Nothing, so the application creates a new database by creating a new GrabAPictureSettings database.

When there are settings to use, the application must determine which settings are available. The database may only contain local or remote settings, but not both. The next step determines whether CurrentSettings.LocalUris contains Nothing. If there are local settings, the application places the name of each of these entries in the lstLocal list box. The application performs a similar task for the remote settings. As a result, the user sees the names of all of the available local and remote wallpaper sources when the application dialog first appears on screen.

Manage Local Database Resources

After the form appears on screen, the user sees the local resources at the top of the form in the Local Sources list. The user can add, edit, delete, or select local resources using the associated controls as shown here:

Let’s look at each of these event handlers in turn. The btnLAdd_Click() event handler is the simplest of the group. It begins by creating a new frmAddEdit using the default constructor. When there are local resources to provide in CurrentSettings.LocalUris, the program supplies them to the AddItem.Resources property. At this point, the application displays the dialog box. If the user clicks Add, rather than Cancel, in the Add Local Resource dialog box (which produces a return value of DialogResult.OK), the application obtains the updated list of resources from AddItem.Resources and places them in CurrentSettings.LocalUris. The application then saves the database by calling GrabAPictureSettings.SaveSettings() with CurrentSettings. Finally, the application displays the newly added item in the Local Sources list.

The btnLEdit_Click() event handler begins by checking whether the user has actually selected an entry to edit by checking lstLocal.SelectedIndex (a value of -1 indicates no selection). If not, the application displays an error message and exits. It then creates a new frmAddEdit() using a special constructor that allows modification of the title bar text and the btnAddEdit.Text property, so that the resulting dialog box is completely customized. You’ll find that there are actually four constructors for frmAddEdit:

• No modification
• Modify the title
• Modify both title and btnAddEdit.Text property
• Modify both title and btnAddEdit.Text property in a remote source setting

Providing this sort of customization reduces the work you need to do and yet provides a better interface for the user. The next step is to set the EditItem.IsEdit property to True, which tells frmAddEdit to fill the fields with data to edit, rather than present a blank form. Again, this is the type of customization that will actually save you time later. (A second property, EditItem.IsRemote, determines whether the data should come from the local or remote wallpaper database—the default is to use the local database.)

The application has to make two decisions when editing a record. First, it has to check whether there is a record to edit. If there aren’t any records, the application displays a dialog box stating as much and exits. Second, it must determine which record to edit. The code passes the value in lstLocal.SelectedIndex onto EditItem.RecordNumber. As the application is currently configured, the contents of lstLocal must precisely match the contents of CurrentRecords, which means that lstLocal remains unsorted. A future update will make it possible to sort the list, if desired, but for now, the application is designed for simplicity of understanding, rather than aesthetic appeal. The remainder of the btnLEdit_Click() code works just like the btnLAdd_Click() event handler, with the result that any changes are immediately saved to the database.

Deleting a record means checking for the required record in the database by name and then removing that particular record. The btnLDelete_Click() event handler begins by checking whether the user has actually selected a record (lstLocal.SelectedIndex must equal a value other than -1). It then creates a temporary array, Temp, of type LocalUri, that will hold one record less than the current number of records. The next bit of code may look confusing at first, but all it really does is move all of the records in CurrentSettings.LocalUris that don’t have the name of the selected record as defined by lstLocal.Items(lstLocal.SelectedIndex) to Temp. The result is Temp has one less record than CurrentSettings.LocalUris when the process is finished. The code then copies the new list of records from Temp to CurrentSettings.LocalUris and saves the result to disk. The final step is to remove the name from the Local Sources list.

Selecting a specific local source is relatively straightforward. The btnLSelect_Click() event handler begins by creating Wallpaper, which is type WinWallpaper. It’s important to remember that modifying the Wallpaper object automatically changes the Desktop wallpaper. You saw how this works in the previous post and it works the same here. The application relies on the index provided by the user’s selection, lstLocal.SelectedIndex, to select the correct wallpaper in CurrentSettings.LocalUris. The application then sets the wallpaper style and provides it with a location in the form of a Uri object, NewUri. The result is that the user sees the selected wallpaper on screen.

Manage Remote Database Resources

The code for managing the remote database resources is almost precisely the same as the code for managing local database resources. In fact, the modifications are mainly cosmetic, such as changes to the frmAddEdit title and button text. However, there are a few distinct differences to note as shown here.

Of course, everything is done using CurrentSettings.RemoteUris in this case because you’re working with the remote settings. In addition, every one of the dialog boxes uses the most complex frmAddEdit constructor, which configures the application for a remote source. I’ll leave it to you to explore this code based on the conversation of the local source workings.

Well, that’s it for frmConfigure. The next post will complete the basic application. We’ll look at how frmAddEdit works. In the meantime, feel free to contact me about any questions at [email protected]. I’ll also start entertaining some additions to this basic application. I have a few in mind, but I’d love to hear your thoughts on the subject. You can find the last post in this series at: Exploring the GrabAPicture Application (Part 12).