กก | Win32 | |
Winnie | ||
Generic | ||
Controls | ||
Dialog-bsd App | ||
Generic Dialog | ||
Canvas | ||
Pens/Brushes | ||
Threads | ||
Folder Watcher | ||
Shell API | ||
OLE/COM | ||
Smart OLE | ||
OLE Automation | ||
Splitter Bar | ||
Bitmaps | ||
Direct Draw | ||
Rationalizing OLEBuilding smart OLE on top of, you know, the other OLE.First of all, you have to tell the worldthat you're going to use OLE. Here's a little class that will do it for you. Just embed an object of this class in some high-level object that's constructed before you do anything with OLE and destroyed after you're done with OLE. In a Windows program, the Controller is a perfect host for UseOle.
Next, you need to create an OLE object that is the provider of interfaces. The abstract base class CoObject declares the method AcquireInterface. The actual class SObject (smart object) provides one particular implementation of CoObject that uses, internally, OLE's infamous IUnknown.
Let's have a look at the implementation of the constructor and the AcquireInterface method. The constructor gets hold of the object by calling the API GetActiveObject and/or CoCreateInstance. The difference between the two is that GetActiveObject will try to get hold of an already running object, whereas CoCreateInstance will try the same, but if it fails, it'll start whatever exe is necessary for this object to run. Some objects actually specify a preference: they want a new server to be started every time CoCreateInstance is called. GetActiveObject lets you bypass that. Notice that this is just one example how you get hold of an OLE object. You may want to play with some of the parameters--for instance, I am passing CLSCTX_SERVER as an argument to CoCreateInstance. That will make sure that the object will live in a separate process from the client. In many cases you'd rather have the object as an inproc server--a DLL that is loaded into the client's address space. For more details, look up CoCreateInstance in your friendly help.
I will explain the strange exception type, HEx, in a moment. Here's our implementation of AcquireInterface that simply calls the QueryInterface method of IUnknown (or, should I say, the unfortunate QueryInterface of the unfortunate IUnknown).
The method AcquireInterface is one of these exceptional Acquire methods of Resource Management that release raw resources. We wan't call it other than inside of the constructor of a smart interface pointer. (By the way, the template parameter is an IID pointer because the compiler won't accept references as template arguments. I'm not sure why.) So here it is, the template for a smart interface pointer.
As you can see, this particular template can't be instantiated. That's because all its constructors are protected. But don't worry, we'll create other classes that will provide their own specialized constructors. Here's one that uses our CoObject (or any other object derived from it) as an interface source.
Finally, let me introduce the HEx class (HRESULT Exception). It is an exception class that is capable of displaying meaningful error messages. For my limited purposes, I chose to simply display the messages directly on the canvas of the main screen. Feel free to implement your own Display method to pop up a message box or something.
There will be sample code for downloading. I just need to explain what Automation is. |