Whenever you expose a Python object via
COM, you actually expose an
object. As described previously, the
interface is used to expose
automation objects. Thus, whenever a Visual Basic program is using a
Python COM object, VB itself is dealing with a COM
IDispatch object. The Python COM framework
IDispatch object that wraps your
Python COM class instance. Whenever the COM framework creates a new
Python COM object, the general process is:
An instance of the selected policy for the object is created.
The policy creates an instance of your Python class.
IDispatch object is created that wraps the
Python policy (which in turn wraps your instance).
IDispatch object is returned to the client
(e.g., Visual Basic).
Thus, when you need to create an
IDispatch from a
Python class instance, you should wrap the object. Unwrapping is the
reverse of this process; if you have an
object that wraps a Python instance, you can unwrap the
IDispatch object, returning the underlying Python
In many cases you don’t need to worry about this. When you expose a COM object that can be directly created via COM, the Python COM framework handles all the wrapping for you. However, there are a number of cases where the explicit wrapping of objects is necessary.
The most common scenario is when you need to expose a COM object via some sort of factory method; that is, rather than allowing the user to create your object directly using VB’s ...