We need to install the Dialog Automation Objects before we can use them. Since there’s no setup program for them, follow these steps:

Once we have the reference to Microsoft Dialog Automation Objects, we only need to open the Object Browser DialogObjects to view the various objects available to us. There are 5 dialog objects, each one giving us access to a specific dialog box. The available objects are:

There are also 5 helper objects which are used by the dialog objects:

We’ll be looking at the dialog objects individually, and within those discussions, we’ll also look at how the helper objects are used.

In order to use any of the Dialog objects, we need to create an instance of the object we want to use. This can be accomplished quite simply using the Set statement:

We’re going to be looking at these dialogs in their order of difficulty, starting with the Color Palette, and continuing through to the Font dialog.

The ChooseColor object implements the Color Palette dialog, allowing the user to change the color of something in an application. This dialog is implemented with all of its custom color functions intact, and can even be opened with custom colors being loaded from somewhere else, either a set list or from the registry:

The object’s properties and single function are rather easy to understand, due to some correctly-named properties:

The helper object named Colors is a collection of custom colors used by the CustomColor property of the ChooseColor object. This helper object has two properties:

At this point in each of the following descriptions, we’re going to be looking at examples of the dialogs. Each of the examples will listing each property or function at least once. This way, you can see a little clearer how to use each one.

This is the first dialog we’ll be calling from a function in a module. In doing so, we can call it more than once without having to rewrite it each time. This is particularly important when it comes to custom colors. Otherwise, we end up with a number of custom color arrays in the registry, one for each form we call the Color dialog from!

Add a module to the project Chapter6.vbp and add the following function to it:

This function creates a new ChooseColor object, then loads the 16 custom colors from the registry. If the registry settings don’t exist yet, all of the individual colors are set to "0", or black. The dialog is centered on the screen, and the initial color is set to the variable "ColorNumber". This is the variable that is passed to this function from the procedure calling it, and is the current color of the item to have its color changed. Three other properties are set before showing the form. The hWnd property is set to 0 so the Color dialog acts modally against the desktop. The PreventCustomColors is set to False. Doing so allows the custom colors to be shown, enabling the "Define Custom Colors>>" button. ShowCustomColors is also set to False, meaning the custom colors are not extended when the dialog is first displayed. Then, the Color dialog is finally shown.

The function continues once the Color dialog is closed. Immediately, the custom colors are written to the registry. Then, the newly selected color is returned to the calling procedure and the function ends.

Add the following code to the Load event of Form1 in Calendar.vbp:

This will retrieve the colors we save to the registry for the calendar’s DayColor and DayNameColor properties. Using the Refresh method ensures the properties are updated every time the calendar is opened. This routine also writes a test setting to the registry, which we’ll be discussing shortly.

Add this code to the mnuViewColorDayColor_Click event:

To ensure the same functionality is available for the calendar’s day names, add the following code to the mnuViewColorDayNameColor_Click event:

Now, add this code to the click event of the mnuToolsRestoreDefaults menu item:

This last routine erases any of the registry settings we’ve previously written in this section. This way, remnants from this chapter aren’t taking up space in your registry forever! It also restores the color properties to their default setting of "black" (0).

This is also where the TestSetting in the registry is used, which was mentioned a short while ago. If the test setting is returned as an empty string, this indicates this area of the registry is empty and the DeleteSettings procedure is not called (if it were called, an error would result). Otherwise, the DeleteSettings procedure deletes the entire section.

The individual procedures mnuViewColorDayColor_Click() and mnuViewColorDayNameColor_Click() save their particular setting to the registry. This would be difficult to do in the SelectColor function without passing a number of parameters to it.

Press F5, or select Start from Visual Basic’s Run menu. Click on the Day Name Color menu item:

The Color dialog will appear, with the black color selected, the custom colors all set to black, and the custom color selection area not extended. Change the current selection, making sure to load up some of the 16 custom colors boxes with new colors. Once you close the dialog, the calendar’s day names will be changed to the selected color.

Now select Day Color from the form’s menu. When the Color dialog appears, the custom colors will be loaded with the ones you’d previously selected. Select a new color and close the Color dialog. The colors of the days in the calendar grid will be changed to the new selection.

Finally, click Restore Default Settings from the Tools menu. The DayColor and DayName color properties will return to black.

The selected color is normally assigned to a particular item in our application. Keeping in mind that the user may have selected some overall Windows color scheme having some semblance of weirdness, we really don't want to assign custom colors to controls. In this case, we need to open the Color Palette dialog without the custom colors being extended, and having the "Define Custom Colors>>" button being disabled.

Note that the menu items are designed with Day Name Color being above Day Color. This follows the layout of the calendar itself, where the day names are at the top of the grid. In the code for the calendar, these items were seen in reverse order from this due to alphabetization by Visual Basic and whoever originally wrote the code. It would be easy to accidentally design the menu items to follow the structure of the code, which would be confusing to the user. Be sure to place first things first and last things last as the user will see them to prevent this kind of confusion.

Since the Dialog Automation Objects are not supplied as source code, we need to determine how they are were developed, in case they’re not supplied to us in the future. The API Viewer on the Add-In’s menu in the IDE provides this information.

The Dialog Automation Objects are implemented as an ActiveX DLL. The individual dialog objects are declared via the Windows API, such as the following declaration for ChooseColor:

The type CHOOSECOLOR is declared in the same area of the DLL’s source code as the above API declaration:

Using this information, the entire ChooseColor class, including the individual properties, is developed. The properties we’re using fill in the blanks in the CHOOSECOLOR type. The ChooseColor.Show property we’ve used in our own code calls the API through the ChooseColorA function, which then uses the CHOOSECOLOR type, and everything is set up correctly to display the Color dialog.

The ChooseFile object gives us access to both the Open and Save As dialog boxes. We’ll go ahead and take a look at both of these dialogs so we can be clear on the differences between the two implementations.

There are a few more properties for this object than for ChooseColor, but still only the one .Show function:

Two more of the helper objects are used by ChooseFile. The first one is FileNames, and is used for multiple file selections:

The second helper object is Filters, which we’ll use to load the Type drop-down box in the dialog via a collection of Filter items:

There are quite a few items in this dialog which will change depending on the specific usage. The directory is one item, as are the file name, filters, title, and multiple file selections. It makes more sense to place individualized code under each Save As menu item than to have a common function and pass all of these variables to and from the function.

Place the following code under the mnuFileSaveAs_Click event in our Chapter6 sample:

Since we’re not actually saving anything at this point, toward the bottom you’ll see "Place save code here". We’ll replace this comment with code to save something in a later chapter.

Start the Chapter6 project and select Save As from the File menu. The Save As dialog will appear as it was shown at the beginning of this section. Change the directory to something different than the default of c:\windows\system\, which is given in the GetSettings statement. Close the dialog, then open it again. Since the SaveSettings statement wrote the directory you chose to the registry, this is the directory which is selected when you open the dialog again.

The Open dialog is almost identical to the Save As dialog in its implementation. Place the following code in the mnuFileOpen_Click event:

Notice the same point about the directory as in the Save As dialog. The GetSetting and SaveSetting statements are, in fact, identical in both cases, except for the registry key being "SaveAsDialog" in one instance, and "OpenDialog" in the other.

After creating the new dialog object ChooseFile1, we make sure it will be centered on the screen. The GetSetting statement does its job to get the default directory, and we specify that the file must exist (which seems strange since we’re looking at a current list of the directory!) Following the naming of the file we’re looking for, we lay out the collection of filters, making sure to include the filter for "All Files *.*". The HideReadOnly property is set to False so the Read-only check box will be shown. The hWnd property is set as in the Color dialog, and we also set MultiSelect to True so the user can select more than one file. Setting OverwritePrompt to True provides a message box to appear before the user overwrites a file that already exists. The Save property sets the dialog for Save or Open functionality, and we also retitle the dialog to something appropriate to the application.

After the dialog is closed, SaveSetting is used to write the directory to the registry, and the procedure finishes with the open statement we’ll fill in later.

The Page Setup dialog is an extra dialog available from the Dialog Automation Objects. Since this dialog is not available from the CommonDialog control, we’ll do a little extra with it.

The properties are, once again, appropriately named for their functions. Notice there are fewer properties for this dialog than even for the Color dialog:

The PrinterDevice object is used for returning the specifics for the printer to be used. At the end of our sample procedure, we’ll enumerate this to see exactly what the values become for our selection:

The Rectangle object is used to set the MinimumMargin and Margin properties, relative to the edge of the selected paper size:

Property Bottom As Long

Property Left As Long

Property Right As Long

Property Top As Long

Add the following code to the mnuFilePageSetup_Click event of the form in Chapter6.vbp:

This isn’t a very complicated procedure, but the list of information it returns is quite large. Because of this, we can’t very well create a function out of it in any practical manner.

When you start the project from the Run menu and select File | Page Setup, the dialog box will appear as specified:

Go through this dialog and make changes to its settings. This dialog acts in the same way as it does in Microsoft Word and other Windows 95 programs. If you change the Margin settings, you’ll notice that it’s not possible to set the margins smaller than the MinimumMargin property settings. Also, the Printer button shows the PrinterSelection dialog:

Selecting a printer is as simple as making a new selection from the Name dropdown box. Pressing the Properties button calls the OEM property page for the selected printer.

When you close all the other dialogs and select the OK button on the Page Setup dialog, a message box will appear, showing all of the selections we made, which are necessary for the printing of a document:

This information is then used to setup whatever document we’re going to print.

A few of these items seem rather cryptic and need a bit of explanation. For instance, the WINSPOOL driver indicates we’re spooling the printing through the Windows Print Manager. The orientation is 1 for portrait, whereas 2 would be for landscape. And Paper Size? For this printer, there are a large number of sizes. 1 is for letter size, or 8 ½ x 11 inches, 5 is for legal size, which is 8 ½ x 14 inches, 9 gives us A4 size paper, being 210 x 297 mm, and so on.

The Print dialog is quite similar to the Page Setup dialog in many respects, to the point where it uses the same type of PrinterDevice object to relay information about the printer. It does have a few more properties to get the job done:

Place the following code under the mnuFilePrint_Click event on the form in our Chapter6 sample:

When you start the Chapter6 sample from the Visual Basic IDE and click the File | Print command, you’ll see this dialog box:

Compared with some of the other dialogs in this group, this one was rather simple.

Following is the discussion for the Font dialog, likely the most complicated one of them all.

As complex as the Font dialog can be, we can still implement it as a function and call the single function from anywhere in our program. This is accomplished through the use of the StdFont object, which encapsulates all of the properties of a font into a single object. All we need to do is call the function that calls the Font dialog, and the font is returned as a StdFont object.

The Font dialog is implemented without any helper objects … except the IFontDisp type for the GetFont() function. We don’t need to worry about this one since Visual Basic takes care of it through OLE:

Add the following function to the module we created earlier in the Chapter6 project:

Place the following code under the mnuViewFontDayNameFont_Click event on the form:

Place the following code under the mnuViewFontDayFont_Click event on the form:

Finally, change the forms Load event by adding the following code:

When you start the program, everything will look as it has before. This is because the default settings we’ve added in the Load event are the same as the calendar’s default settings. Select View | Fonts | Day Name Font from the form’s menu bar, and the Font dialog will appear:

Select a new font from the dialog and click OK. The newly selected font will be transferred into the DayNameFont property and the calendar’s appearance will be changed. Repeat the process with the DayFont property.

You may have noticed that changing the color of the selected font in the dialog has no effect on the font in the calendar.

This could easily be implemented by adding another parameter to be passed to and from the SelectFont function.

While the Windows 95 Common Dialogs are well-implemented and perform their jobs admirably, occasionally we have need to take them a bit further. This is particularly true for the Open dialog. Many custom implementations exist for this box in various programs. For instance, when looking for an icon file, the 16 x 16 versions of the icons are made to show in the standard common dialog. But, in certain programs, the Open dialog has an extension on it to show a "thumbnail", or representation, of graphics files prior to opening them.

Visual C++, and other development packages, provide the common dialogs to developers as templates. These templates are then modified directly for the appropriate usage, and any extensions or other modifications are accomplished on the dialog itself.

In Visual Basic, we don’t have this luxury. We can still do it, but it involves quite a bit of programming to accomplish. For those who feel ambitious, I offer the following steps:

The System Tray Icon Control, Systray.ocx, encapsulates everything necessary to place an icon in the system tray at any time. It has very few properties and even fewer events, but since the control itself is to be placed on a form, the control can set any properties or call any event for the form it’s placed on. Just like the MSVBCalendar control, this control is supplied as source code , so the first thing we’ll need to do is build it.