In the OLE context, an OLE control is an embedded content object, with support for properties and methods through IDispatch, support for property pages with ISpecifyPropertyPages, support for type information with IProvideClassInfo, and support for events through IConnectionPointContainer and individual connection points for each event set. Controls often support property change notification as well.
A control is really a user interface device that transforms those many different types of external events, such as mouse clicks, keystrokes, and phone calls from your bothersome relatives (thank goodness for caller ID!), into meaningful programmatic events. At the occurrence of these programmatic events, some event handler, in what is called the control container, can execute code, such as showing another form when a button is pressed, executing a command, or telling your modem to answer the phone and immediately hang up.
For the most part, there is very little that we have not already seen that is unique to a control. In fact, a control is mostly built of other technologies, and a control container is primarily a compound document container that is also in many ways an automation controller. The few things that distinguish controls are keyboard mnemonics and what are called ambient properties.
Keyboard mnemonics are necessary to allow each control to display an active underlined mnemonic character so that the control can execute its default action when that keystroke is pressed, regardless of what control has the focus. Each control provides its list of mnemonics to the control container, and the control container looks through the lists of all controls whenever a mnemonic key is pressed, informing the appropriate control of the event.
Ambient properties are those that the container supplies through an IDispatch interface implemented on the container site. These properties define the environment or "ambience" for all controls, such as default colors and fonts. Controls generally initialize themselves with these ambient properties, although an explicit change to an object's property becomes persistent for that object and overrides the ambient value.
The facilities that manage mnemonics and ambient properties are handled through the interfaces IOleControl (implemented on the control) and IOleControlSite (implemented on the container site). Chapter 24 brings these interfaces together with all the other things we've seen to create controls and control containers.
If you look back at Figure 1-7 on page 26, you will notice that if you start from OLE Controls at the top, you can eventually work your way down through every other technology in OLE. A control is thus a superset of most other object types in OLE. For this reason, people sometimes use the word "control" to refer to objects that don't necessarily need to be implemented as full-blown controls but that use some of these other technologies. For example, you can create an object that supports an event set without it necessarily having to be a control, with property pages and in-place activation. It might make sense for something like that to be a control, depending on what sort of containers might want to use it, but you don't have to implement a control just to use the lower-level technologies. Keep that in mind when you hear talk about OLE Controls.
You can expect that the market will rapidly become full of very useful OLE controls in the near future. OLE Controls was designed to be a more powerful, flexible, and robust replacement for the VBX standard, which, as you may know, was not all that well designed. Visual Basic will work with OLE Controls in preference to VBX controls, and Microsoft is also planning for controls to take a leading role in extensible user interfaces of future versions of Windows. The technology is well worth your time today.