لطفا منتظر باشید ...
Automation Interfaces
You've already learned that a COM interface is a useful way for Windows programs to communicate with one another, but you've also learned that designing your own COM interfaces is impractical in many cases. Automation's general-purpose interface, IDispatch, serves the needs of both C++ and VBA programmers. As you might guess from your glimpse of Excel VBA, this interface involves objects, methods, and properties.You can write COM interfaces that include functions with any parameter types and return values you specify. IMotion and IVisual, which we created in Chapter 22 are examples. If you're going to let VBA programmers in, however, you can't play fast and loose anymore. You can solve the communication problem with one interface that has a member function smart enough to accommodate methods and properties as defined by VBA. Needless to say, IDispatch has such a function: Invoke. You use IDispatch::Invoke for COM objects that can be constructed and used in either C++ or VBA programs.Now you're beginning to see what Automation does. It funnels all intermodule communication through the IDispatch::Invoke function. How does a client first connect to its component? IDispatch is merely another COM interface, so all the registration logic supported by COM comes into play. Automation components can be DLLs or EXEs, and they can be accessed over a network using Distributed COM (DCOM).
The IDispatch Interface
IDispatch is the heart of Automation. It's fully supported by COM marshaling (that is, Microsoft has already marshaled it for you), as are all the other standard COM interfaces, and it's well supported by the MFC library. At the component end, you need a COM class with an IDispatch interface (plus the prerequisite class factory, of course). At the client end, you use standard COM techniques to obtain an IDispatch pointer. (As you'll see, the MFC library and the wizards take care of a lot of these details for you.)
Remember that Invoke is the principal member function of IDispatch. If you were to look up IDispatch::Invoke in the Visual C++ .NET online documentation, you'd see a really ugly set of parameters. Don't worry about those now. The MFC library steps in on both sides of the Invoke call, using a data-driven scheme to call component functions based on dispatch map parameters that you define with macros.Invoke isn't the only IDispatch member function. Another function your controller might call is GetIDsOfNames. From the VBA programmer's point of view, properties and methods have symbolic names, but C++ programmers prefer more efficient integer indexes. Invoke uses integers to specify properties and methods, so GetIDsOfNames is useful at the start of a program for converting each name to a number if you don't know the index numbers at compile time. You've already seen that IDispatch supports symbolic names for methods. In addition, the interface supports symbolic names for a method's parameters. The GetIDsOfNames function returns those parameter names along with the method name. Unfortunately, the MFC IDispatch implementation doesn't support named parameters.
