Binaryworld - Never mix SingleUse and MultiUse classes ... [ VB -> COM-COM+ ]

ActiveX components written in VB can contain both SingleUse and MultiUse classes at the same time. It usually isn't a good idea to use both types of classes in the same project, however.

When a client creates an instance of a SingleUse class, COM always runs a new instance of the EXE file that exposes that component. Conversely, when a client creates an instance of a MultiUse class, COM tries to use an existing, running EXE application, and lauches a new one only if necessary.

If the same EXE exposes both SingleUse and MultiUse classes, what happens depends on the exact call sequence: if the client creates a SingleUse object and then a MultiUse objects, both of them are exposed by the same instance of the component, and can therefore share values through global variables. On the other hand, if the client creates a MultiUse object and then a SingleUse object, these objects are provided by two differente instances of the EXE file. Because of this impredictability, mixing the two types of classes in the same component is considered to be a bad programming habit.

In general, if a project includes a SingleUse class, all the other classes - if any - should be marked as PublicNotCreatable or Private. This setting is particularly effective when the component exposes a hierarchy of objects: in this case the root object should be the only creatable one in the component, and client applications should be able to get a reference to dependent object only through methods or properties exposed by objects that appear higher in the hierarchy.

Better yet, if you were using SingleUse object only to get a multitasking object, consider the opportunity to use multi-threaded MultiUse components instead.