XEditor obviously needs some way to open and save programs. It should also be able to change the printer setup, the font, and the color of the background or text. Luckily, the CommonDialog control provides all this functionality in a neat package. But there are a few minor problems.
First, the CommonDialog control is actually a control; however, you don’t need a control. In fact, the control can really get in the way. A control has to reside on a surface such as a form, but I frequently use common dialogs in programs that don’t have forms. That’s not a problem for XEditor because I could put the CommonDialog control on the UserControl, although that would mean adding overhead and forcing clients to ship an extra control. But my real objection to the CommonDialog control is that its design is...well, it doesn’t really have a design. It was created back in the old days when controls were the only way to provide packaged functionality, and a whole bunch of properties were sort of thrown together in an ugly mishmash. Nowadays, components that have no visual interface and no events can be provided in a much more convenient format as public classes.
Fortunately, Visual Basic version 5 comes with a non-control component called the Microsoft Dialog Automation Objects (DLGOBJS.DLL). Forget the control. You can create a dialog object and call its methods and properties without any form. I got pretty excited when I discovered this component in the \Tools- \Unsupprt directory of the Visual Basic CD. It’s much easier to use than the CommonDialog control. Unfortunately, when they say unsupported they mean unsupported. I found one serious limitation that I couldn’t work around, and a few other minor problems that I didn’t want to work around. I hope that, eventually, the dialog objects will become a supported part of Visual Basic and will be integrated into the language library.
In the meantime...control! What control? We don’t need no stinkin’ Com-
monDialog control!
I implement common dialogs the old-fashioned way—as a library of procedures. I get rid of the overhead of the control and eliminate the need to ship a separate component file (although the module is also built into VBCore). You end up with a lean and mean layer of Windows and Visual Basic code that uses named and optional arguments to give your code the look and feel (but not the cost) of object-oriented programming.