Micro/scope
February 25, 1998
Norvin Leach
MSDN Online News Editor
A lot of you have been asking about the status of ActiveX again, in the wake of some recent online articles.
Briefly, here's the answer, followed by some practical advice about when to use ActiveX controls and when not to:
ActiveX is a brand name for a visual control framework based on Component Object Model (COM). It's packaging technology that provides a way to package COM components and pop them into applications such as (but not limited to) Web browsers.
ActiveX controls are the descendants of VBXs. You can also consider the components once called OLE Custom Controls (or OCXs) as ActiveX controls.
I'll admit it. Marketing went a little overboard with the term, leading a lot of people to believe that it represented our whole component model.
That's not right. ActiveX is only a packaging technology for COM objects.
Last fall, we trimmed off the excess definitions that had grown up around ActiveX and brought it back to its original, narrow meaning.
As far as emphasizing COM, well, we've emphasized COM for a few years now. It's just a question of whom we talked to and how we talked about it.
Frankly, COM can be a difficult subject for writers to understand. It doesn't lend itself to quick news articles, thus the simplification of the message.
It's sometimes difficult to work with, too. That's why we created frameworks (like ActiveX) to simplify it. Nonetheless, COM has been the strategic core of our component story since 1993.
An ActiveX Control is a COM component that supports the necessary protocols to be used in a visual development tool. In other words, you can visually manipulate it. Now, this doesn't mean that an ActiveX control needs to be visual at run time. It could be visible only during design time. An example of this kind of control is a timer. The developer can see it while he's designing an application, but the end user would never see it.
They include things like the interfaces that visual development tools use to negotiate screen space and the presence of a Toolbox Bitmap entry in the registry.
Well, they are:
Without going into the whole lineage of our object technology, just think of OLE as another framework on top of COM, somewhat similar to ActiveX. It supports compound documents, or documents within documents.
Use ActiveX if you want to build a powerful, small component that accesses system services and can be dropped into a thin client (like a browser). For example, if you want a component that prints or writes to the Registry, use ActiveX.
Similarly, if you want to write a component without learning a new language, use ActiveX. You can build ActiveX components in any language.
If you're writing a simple, lightweight user-interface component, don't use ActiveX. We recommend Dynamic HTML.
Frankly, a lot of things out on the Web, like marquee controls or simple applications, are written as Java applets or ActiveX controls, but shouldn't be. Those things are better off being rendered by Dynamic HTML.
ActiveX is designed for power, not for ubiquity. These controls rely on Win32 features, so they're not available on UNIX or the Macintosh.
Too many people think of ActiveX exclusively as an Internet technology, and that's their measure of success.
ActiveX is not limited to the Internet at all. We're continuing to see growing use of ActiveX in intranets as well as in applications that don't use browsers as front ends. Writers and analysts usually don't take this into account, but that's precisely where the market for ActiveX controls is.
All I know is that, at Comdex 1997, we had 200 developers screaming for one of the last shrink-wrapped copies of that product. Go figure.
Is there anything you want to ask us? Send us mail.