VBX controls, or Visual Basic controls, were the first generation of ActiveX controls. When VBX controls were first developed, they served in dialog boxes as custom controls, things such as progress bars, and so on. Generally, a VBX control doesn't handle data, while an ActiveX control might. In addition, only Visual Basic was able to easily create VBX controls. Programmers who developed in C/C++, for example, had difficulty creating their own VBX controls. However, Microsoft eventually developed a system to create VBX controls using development platforms other than Visual Basic. Microsoft also realized that the concept of VBX (embeddable controls) was a good one, and that these controls were here to stay. In came the OCX (OLE Control) technology; it was development-platform independent, usage-platform independent, and more flexible. Evolution and the name game reared their heads again. Microsoft moved to ActiveX controls more as a change in name than in function. It is common to see ActiveX controls referred to as OCX controls, and vice versa. Some ActiveX controls display data. Some don't do anything other than provide some form of user interface. For example, these controls were on one of my computers:

• BtnMenu Object

• CarPointProximityCtrl

• ChatShowClt Object

• DirectAnimation Java Classes

• HHCtrl Object

• Internet Explorer Classes for Java

• IPTDImageControl.Slmage

• Label Object

• Microsoft MSChat Control Object

• Microsoft Search Settings Control

• Microsoft XML Parser for Java

• PopupMenu Object

• Win32 Classes

All of these controls were installed in the %SystemRoot%\Occache directory. If you are not using Internet Explorer or are not active on the Internet, you probably won't have many of these controls. Note If you don't find an Occache directory, don't panic. It is probably because you don't have any ActiveX controls installed on your computer!

Liar, Liar, Pants on Fire!

Remember when I said previously that OLE controls don't have a user interface? Well actually, I lied a little. It is possible to use RunDll32 to execute some OLE controls. RunDll32 doesn't have a user interface either, and any control that works with RunDll32 must be written specifically for this type of usage. For example, the OLE Active Movie control will run with the command:

%SystemRoot%\System32\rundll32.exe amovie.ocx,RunDll

This opens the Active Movie OLE control (RunDll provides a main window for the control), and Active Movie then displays an Open File dialog box. You might select an Active Movie file (try clock.avi in Windows XP's %SystemRoot% directory) and run it using amovie.ocx. This is possible because Active Movie was written to work with RunDll, and as such, it works. Try this trick with most any other OLE control, and you will get the message, "Missing entry point RunDll," which indicates that the entry point passed in the command was not found. Oh, yes, you can also pass parameters to your OLE control with the command:

RunDll:%SystemRoot%\System32\rundll32.exe amovie.ocx,RunDll
   %SystemRoot%\clock.avi

This command loads Active Movie, loads clock.avi, and allows the user to interact with the control. Try it. Better yet, try this:

%SystemRoot%\System32\rundll32.exe amovie.ocx,RunDll /play /close
   %SystemRoot%\clock.avi

Don't mistakenly insert spaces between the executable file (amovie.ocx in the previous example), the comma, and the entry point (RunDll in the previous example). This will break RunDll without telling you why it failed. Get the hint? I passed a parameter to the Active Movie control to play the clock.avi file and then close it when the .avi file is finished. Active Movie loaded the file specified, played the file, and closed it-all without user intervention. Oh, don't blame me if the clock.avi file is a bit annoying. Actually, RunDll will run more than OLE controls-RunDll will (or will at least attempt to) execute any executable file, including DLL (Dynamic Link Library) and EXE (executable) files. This is true as long as you know the file's entry point and the file to be executed follow the RunDll protocol. For more information, see Microsoft Knowledge Base article Q164787, which can be viewed at http://support.microsoft.com/default.aspx?scid=kb;EN-US;q164787.

Though originally written for Windows 95/98, it has been updated to include support for Windows XP users. Note Don't have amovie.ocx? This control is part of many versions of Microsoft Internet Explorer. Virtually all Windows 9x or Windows 2000 computer have a copy that you can use. You can download from Microsoft; however, the amovie.ocx file is combined with an earlier version of Microsoft Internet Explorer.

Client-Server OLE Applications

Client-server OLE applications make up a substantial number of programs on most Windows computers. Even though the user may not be aware of which client-server OLE applications are installed, there are many. One of the best-designed and best-integrated sets of applications is Microsoft Office, currently released as Office XP. Note Office XP is really Office, version 10. Microsoft has not used the version number as part of the product name for some time. However, many of Office's registry entries and file/folder names use the version number. Just remember that Office XP is Office version 10 (and Office 2000 is Office version 9). Office XP combines word processing (Word XP for Windows), spreadsheets (Excel XP), a database system (Access XP), a presentation program (PowerPoint XP), and a host of utilities (such as Chart). Each of the main applications in Microsoft Office works as both a client and a server application. Some applications-such as the Word Art and Chart utilities-are not designed to run as simple clients. For example, take Word XP (a program that at least I know how to use). Word, as a client is . . . Word. Open Word and edit a document. Write a short letter to someone-it doesn't matter whom. Create something, about a page long, three or four paragraphs. You have Word's functionality in all these paragraphs; you did everything using Word and nothing else. Now things start to get exciting. Insert an object. For grins, insert a drawing into a Word document. Click Insert → Object. Word displays the Object dialog box that lists all the embeddable OLE server objects (see Figure 6.1). Actually, OLE uses an API call to display the dialog box.

Some servers work by totally embedding themselves into Word. For example, Microsoft Photo Editor is called to edit (or select, if you are creating a new object) the picture you have inserted. With Office XP, Word does not embed the server, rather the server is called as a separate process. Word XP displays the standard picture toolbar, and you may edit the picture either by selecting Edit → Photo Editor Photo Object → Edit or by simply double-clicking the image. (I'm jumping ahead some here, but notice how Figure 6.3 shows Word XP with the image of Figure 6.2 embedded as a Microsoft Photo Editor object.)

It is quite incredible that Microsoft Photo Editor (or any other object server, for that matter) works without Microsoft Word having prior knowledge of it. Actually, select (double-click the object, for example) a Microsoft Photo Editor object, and Word gives control to Microsoft Photo Editor. Microsoft Photo Editor then displays its own window along with Word's window, so that the user can switch between the Word document and the object as necessary-I use this same process while I write. When the Microsoft Photo Editor object is not selected, Word allows normal operation (see Figure 6.2). You do context-switching between Word and Microsoft Photo Editor whenever you select something in the document. If your selection is a Microsoft Photo Editor object (see Figure 6.3), Microsoft Photo Editor is put in control; otherwise, Word takes control. A lot of magic goes on behind the scenes here. When saving a complex document containing OLE objects, the objects' servers save the OLE objects when and where instructed to do so by Word. Oops, topic-drift. I'm trying to make everyone an OLE expert. Let's see if I can wrap this up in a nutshell, then connect everything with the registry. So, in a nutshell:

• Client applications may have OLE objects embedded into their documents, and/or have OLE server functionality embedded into their basic functionality.

• This embedding is done at runtime, so the developer knows nothing about what embedding will be done when the program is being written.

• When a client application wants to embed an OLE object, the client application calls OLE to display the Insert Object dialog box to the user. The user then selects the embedded object.

• By selecting the object, OLE allows the client's user interface (menus and toolbars, for example) to be turned over to the server application.

• Server applications may edit the object in place, or may create a special editing window, which may have menu/toolbar support, as appropriate. Usually, complex objects have their own windows for editing just to keep things simpler for the user.

• OLE uses the registry to learn about embeddable server applications.

• OLE server and client applications are identified by CLSIDs; call 'em UUIDs, or GUIDs, if you want. A CLSID is a unique long string of numbers.

• The server application is able to use OLE to tell the client what capabilities the server has. This allows the client to behave in a predictable manner. Note It is possible to embed a purely functional OLE object into a document. From time to time with database programming, OLE controls (ActiveX) and OLE applications (without instance-specific data, such as Microsoft Calendar Control 10.0) are used. OK, I've prattled on about OLE long enough (is that a wild cheer I hear?), so let's get to the registry component of OLE.