It’s time to leave the pre-COM era behind. Let’s look at the server and client code the way that it exists today using COM. It makes sense at this point to look at each line of a client program and study what VB is doing for us.
Suppose that we start with the CChecking class defined in the following code:
' Class CChecking Option Explicit Private m_cBalance As Currency Public Property Get Balance( ) As Currency Balance = m_cBalance End Property Public Sub MakeDeposit(ByVal Amount As Currency) m_cBalance = m_cBalance + Amount End Sub
The VB client code to use this class is the following:
Dim Acct As CChecking Set Acct = New CChecking Call Acct.MakeDeposit(5000) Set Acct = Nothing
In the preceding client code, VB first allocates 4 bytes of memory to
hold the address of an object. It does this in the declaration of
Dim Acct As
the next line, VB does a couple of things. Although it appears that
keyword causes VB to allocate the memory
for the object on the client side, you have learned that this is not
the case with the COM mechanism (in fact, this is not a good
technique when it comes to upgrading objects where there might be two
different definitions, one in the client and one in the server).
Therefore, this code causes the server to allocate memory for the
object. At that point, VB creates a vtable for the CChecking class.
The entries in the vtable are pointers to the public functions of the
class. The memory layout of the
_CChecking interface ...