You're not required to implement the IObjectControl interface in every MTS component, but we highly recommend it. For every component built in Visual Basic that implements this interface, MTS calls three methods as objects are activated and deactivated:
We'll start with the CanBePooled method, even though it's in fact the last one to be called. The CanBePooled method allows you, the developer, to control whether objects based on this component take advantage of object pooling.
Object pooling isn't supported by MTS, so in MTS it doesn't matter what you make this method return. COM+ does support object pooling, however, so if you return True, COM+ might put the object in the object pool when deactivated rather than have it killed. We'll talk more about object pooling in Chapter 15, "A COM+ Overview."
MTS always kills the object when deactivating it; so as long as you're running MTS rather than COM+, it doesn't matter what you have the object return. We recommend, however, that you make all your MTS objects' CanBePooled methods return False. Why is that? Well, there are two reasons:
You might encounter other complications with pooled objects. Until you know exactly which these complications are for your special case, you should avoid pooled objects like the plague. The only bulletproof way of doing this is to have the CanBePooled method return False. Here follows a code example that shows you how to avoid object pooling:
Private Function ObjectControl_CanBePooled() As Boolean ObjectControl_CanBePooled = False End Function |
Just before MTS calls the CanBePooled method, it calls the Deactivate method. The Deactivate method is one of the possible places for cleanup code, the other place being the Activate method. The object, as well as its context object, is still alive when the Deactivate method is called by MTS, whereas both object and context object are already gone when the object's Terminate event is fired. So if you have any cleanup code at all in the Terminate method, you should probably move it to the Deactivate method. But in many cases, especially if you can't or won't take advantage of object pooling, you can leave the Deactivate method empty:
Private Sub ObjectControl_Deactivate() End Sub |
The Activate method is the first of the ObjectControl methods that MTS calls. You can use it for different purposes. Here are three interesting ones:
Here's a small code example that actually takes into account the fact that this object might come from the object pool rather than being newborn. If an object comes from the object pool, it already has a reference to its context object; when it's newborn, it doesn't. By investigating the content of the mobjMySubObject variable, the code snippet also finds out whether the object already has a required subobject. If not, it creates one, using the subobject's ProgId.
Private Sub ObjectControl_Activate() If mobjCTX Is Nothing Then Set mobjCTX = GetObjectContext End If If mobjMySubObject Is Nothing Then Set mobjMySubObject = mobjCTX.CreateInstance("<ProgId>") End If End Sub |
Later in this chapter, you'll see how we use the IObjectControl Activate method to get a reference to the context object and also to set a variable that indicates whether or not the object runs under the control of MTS.