ActiveX Controls

Even today, there's some confusion as to what really constitutes an ActiveX control. In 1994, Microsoft tacked some new interfaces onto its Object Linking and Embedding protocol, packaged them within DLLs, and called them OLE Controls. Originally, OLE Controls implemented nearly the entire OLE Document embedding protocol. In addition, OLE Controls supported the following:

• Dynamic invocation (Automation)

• Property pages (so the user could modify the control's properties)

• Outbound callback interfaces (event sets)

• Connections (a standard way to for clients and controls to hook up the event callbacks)

When the Internet became a predominant factor in Microsoft's marketing plans, Microsoft announced its intention to plant ActiveX Controls on Web pages. At that point, the size of these components became an issue. Microsoft took its OLE Control specification, changed the name from OLE Controls to ActiveX Controls, and stated that all the features listed above were optional. This means that under the new ActiveX Control definition, a control's only requirement is that it be based on COM and that it implement IUnknown. Of course, for a control to be useful it really needs to implement most of the features listed above. So in the end, ActiveX Controls and OLE Controls refer to more or less the same animal.

Developers have been able to use MFC to create ActiveX controls since mid-1994. However, one of the downsides of using MFC to create ActiveX controls is that the controls become bound to MFC. Sometimes you want your controls to be smaller or to work even if the end user doesn't have the MFC DLLs on his or her system. In addition, using MFC to create ActiveX controls forces you into making certain design decisions. For example, if you decide to use MFC to write an ActiveX control, you more or less lock yourself out of using dual interfaces (unless you feel like writing a lot of extra code). Using MFC to create ActiveX controls also means the control and its property pages need to use IDispatch to communicate between themselves.

To avoid the problems described so far, developers can now use ATL to create ActiveX controls. ATL now includes the facilities to create full-fledged ActiveX controls, complete with every feature an ActiveX control should have. These features include incoming interfaces, persistent properties, property pages, and connection points. If you've ever written an ActiveX control using MFC, you'll see how much more flexible using ATL can be.