Saturday, 9 March 2013

Automation


Automation

An Automation server lets other applications tell it what to do. It exposes functions
and data, called methods and properties. For example, Microsoft Excel is an Automation
server, and programs written in Visual C++ or Visual Basic can call Excel functions and
set properties like column widths. That means you don't need to write a scripting
language for your application any more. If you expose all the functions and properties
of your application, any programming language that can control an Automation server
can be a scripting language for your application. Your users may already know your
scripting language. They essentially will have no learning curve for writing macros to
automate your application (although they will need to learn the names of the methods
and properties you expose).
The important thing to know about interacting with automation is that one program is
always in control, calling the methods or changing the properties of the other running
application. The application in control is called an Automation controller. The

application that exposes methods and functions is called an Automation server. Excel,
Word, and other members of the Microsoft Office suite are Automation servers, and your
programs can use the functions of these applications to really save you coding time.
For example, imagine being able to use the function called by the Word menu item
Format, Change Case to convert the blocks of text your application uses to all
uppercase, all lowercase, sentence case (the first letter of the first word in each
sentence is uppercase, the rest are not), or title case (the first letter of every word is
uppercase; the rest are not).
The description of how automation really works is far longer and more complex than
the interface summary of the previous section. It involves a special interface called
IDispatch, a simplified interface that works from a number of different languages,
including those like Visual Basic that can't use pointers. The declaration of IDispatch is
shown in Listing 13.2.
Listing 13.2 IDispatch, Defined in \Program Files\Microsoft Visual Studio\VC98\Include\oaidl.h
MIDL_INTERFACE("00020400-0000-0000-C000-000000000046")
IDispatch : public IUnknown
{
public:
virtual HRESULT STDMETHODCALLTYPE GetTypeInfoCount(
/* [out] */ UINT __RPC_FAR *pctinfo) = 0;
virtual HRESULT STDMETHODCALLTYPE GetTypeInfo(
/* [in] */ UINT iTInfo,
/* [in] */ LCID lcid,
/* [out] */ ITypeInfo __RPC_FAR *__RPC_FAR *ppTInfo) = 0;
virtual HRESULT STDMETHODCALLTYPE GetIDsOfNames(
/* [in] */ REFIID riid,
/* [size_is][in] */ LPOLESTR __RPC_FAR *rgszNames,
/* [in] */ UINT cNames,
/* [in] */ LCID lcid,
/* [size_is][out] */ DISPID __RPC_FAR *rgDispId) = 0;
virtual /* [local] */ HRESULT STDMETHODCALLTYPE Invoke(
/* [in] */ DISPID dispIdMember,
/* [in] */ REFIID riid,
/* [in] */ LCID lcid,
/* [in] */ WORD wFlags,
/* [out][in] */ DISPPARAMS __RPC_FAR *pDispParams,
/* [out] */ VARIANT __RPC_FAR *pVarResult,
/* [out] */ EXCEPINFO __RPC_FAR *pExcepInfo,
/* [out] */ UINT __RPC_FAR *puArgErr) = 0;
};
Although IDispatch seems more complex than IUnknown, it declares only a few more
functions: GetTypeInfoCount(), GetTypeInfo(), GetIDsOfNames(), and Invoke(). Because it
inherits from IUnknown, it has also inherited QueryInterface(), AddRef(), and Release().

They are all pure virtual functions, so any COM class that inherits from IDispatch must
implement these functions. The most important of these is Invoke(), used to call
functions of the Automation server and to access its properties.


No comments:

Post a Comment