What Are ActiveX Controls?
There's still some confusion about what really constitutes an ActiveX control. In 1994, Microsoft tacked some new interfaces onto its Object Linking and Embedding (OLE) protocol, packaged them in 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 for clients and controls to hook up the event callbacks)
When the Internet became a dominant factor in Microsoft's marketing plans, the company 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. That 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, in order 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 are more or less the same animal.These days, Microsoft .NET (and especially ASP.NET) emphasizes pure HTML running in the browser as the dominant Web interface. The idea is to reduce the dependencies between your Web site and specific kinds of browsers. However, ActiveX controls work the same way they've always worked, and if you know that the browser on the other end of your Web site is Microsoft Internet Explorer, ActiveX controls will still offer a means of providing a rich user interface for the client.Developers have been able to use MFC to create ActiveX controls since mid-1994. However, one downside to 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 her system. In addition, using MFC to create ActiveX controls forces you make 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 that the control and its property pages must use IDispatch to communicate with each other.
To avoid the problems described so far, you can 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—including 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.