I awoke this morning to the sound of my alarm clock. As usual, I pressed the snooze button to get a few extra minutes of rest. After repeating this a couple of times, I finally turned off the alarm by moving a switch on the clock. Then I went to the bathroom, where I turned a doorknob to open the door and flipped a switch on the wall to turn on the light. I grabbed the handle on my shower door, moved the door aside, pushed up a round knob to turn on the shower, and rotated the knob to adjust the water temperature. When I left the bathroom, I flipped the light switch again to turn off the light, went downstairs, and then grabbed another handle to open the refrigerator to find some breakfast. After breakfast, I used a lever on the sink faucet to turn the water on and rinsed my dishes.
When I finally got to my study, I flipped one switch to turn on the desk light and rotated another knob to turn on a halogen lamp and adjust its brightness. Then I flipped a rocker switch to turn on my computer's monitor. On the screen appeared the applications I've been using to write this book. They too display an assortment of buttons, switches, and dials, as do the mouse and the keyboard I use.
All of these devices—buttons, switches, knobs, handles, dials, levers, and so on—are examples of controls. The first designers of graphical user interfaces created on-screen controls with the express purpose of imitating known mechanical controls. People, they thought, were used to mechanical controls, so they would naturally understand things that looked and behaved the same way on a computer screen.
A control, be it mechanical or computer-generated, is a device for transforming a human intent into a precise signal that triggers some response. The knob on my shower lets me carry out my intent to turn on water and adjust the temperature. The actions of lifting and twisting are transformed into the precise response of opening two valves and adjusting the mixture of water from the hot and cold water pipes. A push-button control on my computer screen transforms my mouse click into an event that triggers a specific piece of code. Pressing keys on my keyboard does exactly the same thing. Through the design of a control, as well as the labeling or visual aspects of that control and the context in which it appears, an end user can decide what a control will do when activated in some way and whether using that control is an appropriate thing to do. By using controls, programmers build much of the user interface of an application. Controls are among the most powerful building blocks for creating applications, perhaps even more powerful than functional libraries.
In the early versions of Microsoft Windows, only a few controls were available: the push button (momentary switch), the radio button (mutually exclusive options), the check box (mutually inclusive options), the list box (variable list of exclusive or inclusive options), the edit control (text field), and the label and other static controls. Building a custom control—one of your own design—was difficult and did not allow you to extend the system very easily. Over time a few attempts have been made to make the creation of custom controls easier. Windows 3.0 introduced some standards for doing so, but they were weak. Visual Basic introduced the Visual Basic Extension, or VBX, which turned into a powerful but somewhat inelegant design for custom controls as well. When 32-bit operating systems became the norm, Microsoft discovered that the VBX standard did not carry over to 32-bit systems very well, so a new standard was called for.
The result is the technology named OLE Controls, in which an OLE control is the name we give a custom control built using OLE technologies. As you might remember from Figure 1-7 on page 26 in Chapter 1, OLE Controls builds on nearly every other technology in OLE, including in-place activation, OLE Automation, and Property Pages. For this reason, an OLE control is a superset of nearly any other type of component in OLE—you can use a control as a compound document content object, as an automation object, or simply as a data source. Because anything you can do in OLE is somehow encompassed in an OLE control, the OLE Controls technology is sometimes identified as what OLE is all about. Whether this is true, OLE controls—as COM components with a large number of interfaces—are powerful extensions of the existing component system. They also work well on both 16-bit and 32-bit operating systems.
Microsoft has great plans for using OLE Controls in future system shells. This will allow end users to quickly create their own user interface using existing controls or to build a new control based on those that already exist—all in a way that makes sense to the users. Microsoft's development tools are targeting the construction of applications, especially of the user interface, using OLE Controls, much as Visual Basic has done in the past. At the time of writing, Microsoft Access 2 already supports OLE Controls in building database forms.
However—and this is a big however—OLE Controls as a technology is still in its infancy at the time of writing this book. (This is especially true when OLE Controls is compared to the other technologies we've seen, which are generally more mature and solid.)1 As a consequence, there is a conspicuous lack of well-known standards about what an OLE control should do at a minimum. The same is true for what sorts of features a container for OLE controls should have in order to take advantage of the content and functionality of most controls. In this chapter, we'll first examine the technical aspects of OLE Controls—which interfaces are used for what reasons, along with a few additional interfaces we haven't yet encountered. We'll then take a brief look at some samples: a version of Polyline enhanced to work mostly as a control and a version of Patron enhanced to work somewhat as a control container. What do I mean by "mostly" and "somewhat"? As I was writing this code, I had only a few standards to work with, so I cannot call these samples definitive or necessarily correct in all regards. They are certainly not complete as far as features go. My purpose for providing these samples is to give you an idea of how containers and controls interoperate through the OLE Controls technology.
This technology is indeed rich. As such, it in itself will be the topic of entire books.2 Development tools such as the OLE Controls Development Kit (CDK), which comes with Visual C++, and the Microsoft Foundation Classes make the creation of a control nearly trivial. Visual C++ in particular provides a Control Wizard that automatically generates most of a control, leaving its specific features for you to implement yourself.3 You basically never see the interfaces and the architecture that we'll discuss in this chapter.
So while we'll see the details of the technology and how a minimalist OLE control and control container manifest themselves in straight C++ code, we will generally not see how you would work with this technology yourself. Again, the samples provided here are simply for demonstration and are not intended to be model implementations. In the coming years, I'm sure that we'll see many great tools for building OLE controls and for building applications with them (as well as other components). As I've mentioned for the other complex OLE technologies, such as OLE Documents and OLE Automation, I encourage you to take advantage of these tools. After all, people use very powerful mechanical tools to efficiently fabricate the necessary mechanical controls we use in our day-to-day lives. At this point in the history of computing, we're ready to see a tremendous explosion in the number of on-screen controls and in the number of applications that are built with them.
1 This applies even to Connectable Objects, licensing, self-registration, Property Pages, and so on, which were originally defined for the purposes of OLE Controls. These simpler pieces of the puzzle are themselves stable and mature. What I'm talking about here is a full-blown control object, which combines many of these lesser technologies in a higher form. |
2 Some are in the works at the time of writing, although not by this author. |
3 Work is under way at the time of writing to provide control container support as well. |