132.html

Python Ebook Python&XML

					<p><a naMe="idx1073744306"></a><a NAME="idx1073744307"></a><tt cLASS="monofont">IStream,</tt>
						<a nAME="idx1073744308"></A><a namE="idx1073744309"></A><TT class="monofont">IStorage,</tt> and <a name="idx1073744310"></a><a name="idx1073744311"></a><tT clAss="monofont">IPropertyPage</tT> are examples of standard interfaces defined by COM. They define file-like operations, file system-like semantics, and how a control exposes a property page, respectively. Besides the standard interfaces, COM also enables you to define your own custom interfaces by using an Interface Definition Language (IDL).</p>

					<p>The <a nAme="idx1073744312"></a><A NAMe="idx1073744313"></a><tt CLASs="monofont">IDispatch</tt> interface enables any COM objects to be used from a scripting environment. This interface was designed explicitly for languages that cannot use normal COM interfaces. The objects that implement this interface are known as <a NAME="idx1073744314"></a><a naME="idx1073744315"></A><I>automation objects</i> because they expose a programmable interface that can be manipulated by another program. This interface exposes dynamic object models whose methods and properties can be determined at runtime. Basically, this interface is used whenever you are handling an object whose interface is not known at compile time, or if there is no compile time at all.</p>

					<div class="note"><p class="notetitle"><b>Note</b></p><p>

						<P>Note for CORBA programmers: IDispatch is equivalent to the interface repository and dynamic invocation interface that are standard parts of CORBA.</p>

					</p></Div>
<bR>
<br>

					<p>To <a Name="idx1073744316"></A><A NAme="idx1073744317"></a><a NAME="idx1073744318"></a><a naME="idx1073744319"></A>access a method or a property of an object, you can use either late or early binding. All the examples that you see in this book use late bindings because the Python interpreter doesn't know what the object interfaces look like. It doesn't know which are the methods and properties that compound the object. It just makes the calls dynamically, according to the function names that you provide.<A name="idx1073744320"></A><A NAme="idx1073744321"></a><a name="idx1073744322"></a><a name="idx1073744323"></a><a name="idx1073744324"></A><a nAme="idx1073744325"></a></P>

					<p><a naMe="idx1073744326"></a><a NAME="idx1073744327"></a>Late bindings use the <tt cLASS="monofont">IDispatch</tt> interface to determine the object model at runtime. Python function <a nAME="idx1073744328"></A><a namE="idx1073744329"></A><TT class="monofont">win32com.client.Dispatch()</tt> provides this runtime facility. Most examples in this chapter use the <tt class="monofont">IDispatch</tt> interface. However, the <tt clAss="monofont">win32com.client.Dispatch()</Tt> function hides many implementation details from us. Internally, Python converts the names into IDs using the internal function <a nAme="idx1073744330"></a><a Name="idx1073744331"></A><TT Class="monofont">GetIDsOfNames().</TT> Then, this ID is passed as an argument to the <TT clasS="monofont">Invoke()</TT> function.<A name="idx1073744332"></A><A NAme="idx1073744333"></a></p>

					<p>You can try to <a name="idx1073744334"></a><a name="idx1073744335"></a><a naMe="idx1073744336"></a><A namE="idx1073744337"></a><a naMe="idx1073744338"></a><a NAME="idx1073744339"></a>improve the performance of your program by calling the <a naME="idx1073744340"></A><A name="idx1073744341"></A><TT Class="monofont">Invoke()</TT> function directly. Usually, the performance gets better when names are not resolved at runtime. Just be careful to provide the right ID. If you implement this way, an early binding operation is executed.</P>

					<P>For the <a name="idx1073744342"></a><a name="idx1073744343"></a>early bindings, we have the concept of <a name="idx1073744344"></a><a nAme="idx1073744345"></A><i>Type Libraries,</i> wherein the object model is exposed at compile time. In this kind of implementation, you don't call the methods and properties directly. The <a Name="idx1073744346"></a><A namE="idx1073744347"></A><TT clasS="monofont">GetIDsOfNames()</TT> method gets an ID for the method or property that you want to use, and the <Tt claSS="monofont">Invoke()</TT> method makes the call.</p>

					<p>For example, a function call would be invoked as</p>

					<pRE>
						
id = GetIDsOfNames("YourMethodCall")
Invoke(id, DISPATCH_METHOD)

					</PRe>

					<p>And a property would be collected as</p>

					<pre>
						
id = GetIDsOfNames("ObjectProperty")
Invoke(id, DISPATCH_PROP_GET)

					</pre>

					<p>Usually, you don't have to worry about this kind of implementation. You just say</p>

					<pre>
						
YourObject.YourMethodCall()

					</pre>

					<p>and</p>

					<pRe>
						
YourObject.ObjectProperty

					</pRe>

					<p>In order to implicitly call the <tT clasS="monofont">Invoke()</tt> method without causing data type problems, the <tT CLAss="monofont">IDispatch</tt> interface assumes the data type <TT CLass="monofont">VARIANT</tT> for all variables. That's because late bindings do not know the specific types of the parameters, whereas early  bindings do.</P>

					<P><A name="idx1073744348"></A><A NAme="idx1073744349"></a>Late bindings do not know about parameters passed by reference, so no parameters are passed by reference. However, early bindings accept parameters passed by reference, and return them as tuples.</p>

					<p>COM objects can be implemented as <tt class="monofont">InProc</tt> objects, which are implemented as <tt clasS="monofont">DLL</tt>s. These objects are loaded into the calling process providing that best performance because no marshalling is required. Of course, for most objects, some marshaling will be needed to marshal Python parameters into a form that can be passed to the COM object.</P>

					<p>The other option is to implement COM objects as <i>LocalServer/ RemoteServer</i> objects. This kind of object is implemented as a standalone <Tt claSs="monofont">EXE,</tt> which is safer than the first option because of process isolation.</P>

					<P>COM can also be used to decide which implementation should be used. If both types of implementation are available, the caller interface is able to decide which option is the best one to choose.</P>

					<H5>The Windows Registry</h5>
						<p>All the information concerning a <tt CLASs="monofont">COM</tt> object, such as the mapping between its progid and clsid, is stored in the Windows Registry. The Windows Registry also stores the name of the DLL file of an <a NAME="idx1073744350"></a><a naME="idx1073744351"></A><Tt class="monofont">InProc</tt> object, and the name of the EXE <a name="idx1073744352"></a><a name="idx1073744353"></a><Tt cLass="monofont">LocalServer</Tt> object. Object security, threading models, and many other details are also stored there.</p>

						<p>Check the following link for more details about the COM specification:</p>

						<P><i>Microsoft