When OLE Custom Controls were first introduced, they were offered as a separate Software Development Kit (SDK). With current versions of Windows, and as of Visual C++ 2.0, Microsoft has added OLE Custom Controls to Windows and Visual C++. Visual C++ 4 offers built-in support for OLE controls and support for OLE control container applications. A custom OLE control AppWizard helps programmers develop OLE controls. Figure 10.1 shows Visual C++ 4's AppWizard, where the OLE ControlWizard is selected.
Figure 10.1. Visual C++ 4's AppWizard creating an OLE control using the OLE ControlWizard.
This means that now there is one less development tool that you, the programmer, must integrate by hand. Using Visual C++ 4's OLE controls AppWizard lets you create an OLE control without using any external products or features.
NOTE
Versions of Visual C++ prior to version 4 don't offer integrated OLE control development. You must use the OLE control SDK (called the Control Development Kit, or CDK) with these earlier versions of Visual C++. Though developing OLE controls with versions of Visual C++ earlier than version 4 is possible, it will be easier if you upgrade to Visual C++ 4 if you intend to develop OLE controls. Also, Visual C++ 4 (and Visual Basic 4) let you place OLE controls on the Resource Palette and, from there, place them on your forms. In previous versions, you had to hand-code the interface between the OLE control and your application. Another good reason to upgrade to Visual C++ 4!
When using the OLE controls CDK to develop 16-bit controls, you must use Visual C++ 1.5.01 or later, which includes some fixes and changes to the Visual Workbench and ClassWizard to facilitate developing OLE Custom Controls.
Where has the "2" in "OLE-2" gone? Microsoft has announced its intention to change OLE's name from OLE-2 to just OLE. This change was made to allow Microsoft to expand OLE without changing the name, meaning that there will never be an OLE-3 or OLE-4.
This chapter covers the basics of OLE Custom Controls. The specifics of OLE Custom Controls and their use in database development will be discussed in later chapters.
The term OLE Custom Controls is a mouthful. Some publications use the term OCX for OLE Custom Controls (OCX is the accepted extension for an OLE control), but this book uses the term OLE controls, which is what Microsoft uses. The OLE Custom Controls Development Kit is referred to as the CDK when referring to Visual C++ 1.5x and 2.x. Visual C++ 4 doesn't have a separate CDK component.
WARNING
It's possible to have some rather nasty accidents when you're using applications that work with the registration database. On more than one occasion, I've destroyed the registration database, and the results are nothing short of awful. Some versions of Windows will refuse to run; others will run, but not well; and still others will never notice the loss of the registration database.
Make sure that you have a backup of your current registration database. Many versions of RegEdit, the utility that is used to make manual modifications to the registration database, also export the registration database. For Windows 3.x, the file is REG.DAT. For Windows 95, back up the SYSTEM.DA? and USER.DA? files. Some of these files might have the hidden attribute and therefore won't be visible unless you use the command DIR /AH. Windows NT has a similar set of database files to store the registry. You can look in \WINNT\SYSTEM32\CONFIG and back up all the files in this directory.
This information is also backed up when you create your emergency recovery disks for Windows 95 and Windows NT. But these disks will only cover the registry as it existed when you first installed your operating system. Any changes made by applications you installed later would be lost.
Remember: Back it up or lose it. Generally, losing the registration database means reinstalling Windows and many (if not all) of your Windows applications.
NOTE
Microsoft has included a utility called CFGBACK that can be used to back up the registry under Windows 95. Also, the utility ERU can be used to back up all critical files that are part of your Windows 95 system (CFGBACK backs up only the registry). The user would run these utilities before making changes, such as adding new software or hardware, or any time he wanted to make a backup copy of his configuration.
The CFGBACK utility can be found on the Windows 95 CD in the directory \OTHER\MISC\CFGBACK. It's also included as part of the Windows 95 Resource Kit. The ERU utility can be found in \OTHER\MISC\ERU, but it's not part of the Windows 95 Resource Kit. Both of these utilities are documented with .TXT files.
The backup created with the ERU utility is restored using the ERD utility—ERD.E_E. You must copy it to a directory on a writeable disk and rename it ERD.EXE in order to use it.
The OLE Control Development Kit was a separate component of the Visual C++ 2.0 system. However, with Visual C++ 4, OLE control support is built-in and has no installable components. The following features moved from add-ons in version 2 to built-ins in version 4:
Many of the new tools used to create OLE controls appear on the Visual Workbench Tools menu:
In Visual C++ 4, these functionalities are built into the IDE. This makes developing OLE controls simpler and alleviates the need to do many mundane tasks by hand. Visual C++ 4 has the following functionalities:
Figure 10.2. Visual C++ 4's ClassWizard, showing the OLE Automation tab.
Many of the new tools used to create OLE controls appear on the Visual Workbench Tools menu:
Figure 10.3. OLE Object View, showing the OLE Grid Control.
Chapter 16, "Creating OLE Controls with Visual C++ 4," describes each of these tools in detail.
For earlier versions of Visual C++ that use the CDK, the CDK is installed in a directory called either CDK32 (for Visual C++ 2.0) or CDK16 (for 16-bit versions of Visual C++) under Visual C++'s main directory (MSVC20 in most installations). Visual C++ 4 is installed in the directory MSDEV, and the OLE control components are integrated directly into the standard Visual C++ directory structure.
NOTE
Even though this book deals with the 32-bit compiler for Visual C++ 4.0, 16-bit products are mentioned because some programmers might have to maintain compatibility with existing versions of Windows for their applications.
There is a directory that contains sample source code for a number of OLE controls included with Visual C++ 4. The sample controls that are supplied with Visual C++ 4 (in the \MSDEV\SAMPLES\MFC\CONTROLS folder on the Visual C++ 4 CD) include the following:
OLE controls are supported by a number of runtime DLL files when they're developed with either Visual C++ 1.5x or Visual C++ 2.x. OLE controls that are developed with Visual C++ 4 are supported directly by the system OLE DLL files. The Visual C++ 2.x and Visual C++ 1.5x DLL files include the following:
The appropriate DLL files are also installed in the WINDOWS\SYSTEM directory (or WINNT\SYSTEM32 for Windows NT) and are registered by the CDK setup program. If the registration database becomes corrupted and has to be replaced, you'll need to reinstall the CDK to use OLE controls when using Visual C++ 1.5x or Visual C++ 2.x. Of course, Visual C++ 4 eliminates this problem, because it doesn't have separate DLL files for OLE controls.
This section defines a few of the more common terms used with OLE. We've included these definitions here because many of these terms aren't defined in a single location. Understanding each of them will greatly help you comprehend OLE and OLE controls.
OLE stands for Object Linking and Embedding. It was created as a wrapper for the original concept of Dynamic Data Exchange (DDE). OLE defines a set of standard interfaces to objects, such as IUnknown.
An object is an item that is placed in a document. Objects may be either linked, meaning that the object's data is external to the containing document, or embedded, meaning that the object's data is internal to the containing document. Objects may also be referred to as servers.
A container is a document into which objects may be embedded or linked. Generally, the term container refers to either a container application such as Word, Excel, or Access, or a container document such as a Word document, an Excel worksheet, or an Access report or form. Containers may also be referred to as clients.
A linked object is an object whose basic data isn't part of the containing document. The information that is part of a linked object tells where the actual information is located and includes a view of the object.
When the user decides to change the object, the object's server uses the link information to retrieve the object's data. When a linked object is modified outside the container application, the container's representation of the object's data is also updated.
An embedded object's data resides in the container document. Changes to the embedded object's original source data don't affect the embedded object or its data. An embedded object can be modified if necessary.
A document with embedded objects is larger than a document that has linked objects, because the embedded objects' data must be included in the containing document.
A Windows object is an OLE object that defines at least one interface, IUnknown.
Each object must provide a function table for each interface that the object supports. When you use ControlWizard to develop OLE controls, the details of the interface are managed for you.
An OLE automation server is an application that exposes a programmable object (the server's functionality) to an OLE container application. This exposure is done using the IDispatch interface.
For example, a Geographical Information (GIS) program could expose its zip code validator to other applications for their own use. That way, a mail list program (perhaps part of an Access database) could verify that the street, city, state, and zip code portions of an address are correct before printing a mailing label.
Events are simply things that happen (a crummy, but accurate, definition). A Windows event could be an action such as a mouse message (movement or clicking), a keyboard action, or perhaps a timer message (as in the digital clock OLE control).
A server is an application that is the source, or creator, of an object. Even if the preceding sentence says it all, it says nothing. It is simply jargon used to explain more jargon. No wonder Windows programming is getting so complex! The following section will clarify this definition.
Let's try to define a server again. Rather than using computer terms, let's try something else: a company picnic. I've planned the picnic because I want to butter up my boss (the chairman of the board) so that I can ask for a raise.
I set up a table, put on a tablecloth, silverware, and napkins, and ask each of my employees to bring something to eat.
The company, which is sponsoring the picnic, is the container application. The table is the document. Actually, the table is a compound document, because it has objects on it. (In OLE terminology, the objects would be embedded or linked; however, be careful how you embed a bowl of potato salad in the table. The results might be less than appealing if you embed the bowl too aggressively.)
You could place a bowl on the table with a picture of potato salad and a small card inside, telling those who want potato salad that "the potato salad is in the cooler." This would make the potato salad a linked object because its data (the actual salad) is stored externally to the main document (the picnic table).
However, in keeping with picnic tradition, you place an object full of potato salad on the table. Because you brought the potato salad, you are the server, the potato salad is an object, and the table is a compound document. (Please don't say I'm nuts—yet.)
When you brought your potato salad, you didn't bring it on a nice plate with the necessary garnishes. You transported it in a plastic Tupperware container. As president of the company, I ask you to present your potato salad, and you do so by putting it on an attractive plate with a little parsley on the side to make it look good. Now that the potato salad is presentable, I put it in the center of the table.
It just so happens that the company's chairman of the board (my boss, the person for whom we're having this picnic) has sampled your potato salad. He thinks he knows everything about salads, and he wants to change yours by adding some pepper. My boss (representing the user) tells me (the application) to get you (the server) to make the change. (He couldn't really tell the table; it's just a document.) You comply by adding the pepper, and you put the potato salad back on the table.
I figure that having you change your salad would satisfy my boss, but it doesn't. My boss (the user) tells me (the application) that he thinks the salad would look better at the end of the table, so I move it. Because I'm only moving the salad and not changing it, I can do this myself. Of course, each time I move the salad, you step in and adjust the plate so that it looks just right.
Now you can say I'm nuts, but basically, that's how OLE servers and containers work!
Just like the movies, let's give proper OLE credit to the players (cue the music):
The Company: The application (the container).
You: The object's server.
My Boss: The user.
The Potato Salad: The object to be embedded.
The Table: The compound document.
At this point you are well into the introduction to OLE Controls but you haven't learned about OLE Controls yet. You're probably wondering what an OLE Control is. Microsoft defines an OLE Control as being "implemented as an OLE compound document object with visual editing support. OLE Controls have additional capabilities beyond those of ordinary OLE objects, such as the ability to fire events."
An OLE control is a program that behaves like an object whose working interface with the user is through the OLE control's user area. An OLE control's format or layout generally is fixed, but its contents may vary. For example, a programmer can create an OLE control that looks similar to the standard list box found in many dialog boxes but that includes special properties such as multiple columns.
In Chapter 16 you will create an OLE control that is a digital clock. In this OLE control, you display the current time in a font and style that the end user can define. In fact, you could use the digital clock control in an Access 95 form or report to display the current time or embed it into a Word document. (However, Word and Excel don't fully support OLE controls in documents, so the actual performance of the OLE control in Word probably will be less than satisfactory.) When an OLE control is embedded into a Word or Excel document, it basically becomes an OLE automation server, which might not be the desired effect.
An automation server is an application that exposes a programmable object to another application. OLE controls become automation servers in Word and Excel documents because the current versions of Word and Excel don't support events. Events are responses by an OLE custom control to an outside action on the control, such as a mouse click.
One thing to keep in mind is that Microsoft has committed to supporting OLE controls in its database and development tools. Don't be surprised if Microsoft supports OLE controls in future versions of both Word and Excel.
You can use OLE controls in many different applications. OLE controls let a developer interface with other applications such as Microsoft Access. Programmers also can add extensive flexibility using OLE controls in their applications. OLE controls can also add functionality to an existing application. A classic example is adding the OLE control digital clock, which you develop in Chapter 16, to the forms of an Access database program. Another possible OLE control is a calendar that displays the current month, perhaps with buttons to scroll forward and backward. There are many situations in which a person using an Access database might need to know a date or a date's day of the week.
As this book was being written in late 1995, the only application that fully supported OLE controls was Microsoft Access. This situation is rapidly changing. Visual C++ 4 applications can support OLE controls in dialog boxes. (See the sample programs OLE Container and OLE Control in the CHAPTR10 folder on the CD that comes with this book.) With this new flexibility, we can expect that there will be many, many OLE control-aware applications that will allow the embedding of OLE controls in dialog boxes or even documents. With Microsoft Access, you can place OLE controls in both forms and reports.
Access can work with OLE controls that you create, and also with the many aftermarket OLE controls that will be available for Access. Visual C++ 4 comes with a number of useful OLE controls that you can embed into your applications:
Word for Windows and Excel both allow the insertion of OLE controls into documents. However, when an OLE control is subsequently copied to the clipboard, or when the container document is saved, the OLE control ceases to be an OLE control and becomes a standard OLE automation server—with a few minor differences.
Another excellent use of OLE controls created with Visual C++ 4 is with Visual Basic 4. Since Visual Basic 4 is also a 32-bit application, it can use all the OLE controls you create with Visual C++ 4.
It's still possible to create OLE controls that can be used in containers that don't support OLE controls. What must be taken into consideration is that the control won't receive event notifications (such as mouse actions or certain Windows messages) other than those necessary to manage the embedded control, such as resizing and movement.
This chapter introduced OLE controls, the CDK for Visual C++ 1.5x and 2.x, and the OLE concepts that make up OLE controls. The following topics were covered:
In Chapter 16, you will develop an OLE control that can be embedded into any Visual C++ 4 application dialog box.
