On Dec 2, 2009, at 9:53 PM, Brent Fulgham wrote:
To add insult to injury, all of these interface classes also require each concrete implementation to implement a stub QueryInterface, AddRef, and RemoveRef method.
Yes, this is one of the downsides of COM. Some COM developers use ATL (or similar) to avoid boilerplate implementations of AddRef/Release/ QueryInterface.
For my own purposes, I created a concrete class "WebUIDelegate" that stubs all methods as E_NOTIMPL and provides the boilerplate QueryInterface, AddRef, etc.. I subclass from *this* class as my delegate, which allows me to simply write one method that does the menu customization.
Sounds similar to what we do.
Couldn't the Windows version of WebKit either stub the IWebUIDelegate with the requisite E_NOTIMPL stubs, or perhaps ship with a set of pre-generated stub classes like the one I just created, to avoid this kind of drudgery?
COM interfaces are pure virtual, so there is no implementation of IWebUIDelegate in WebKit. We could provide a concrete CLSID_WebUIDelegate that was instantiatable via (our version of) CoCreateInstance but you wouldn't be able to subclass it. We don't export any of the WebKit COM API directly through DLL exports. All of these conventions were critically important when the COM API was remotable via DCOM in order for Drosera (Web Inspector in its previous iteration) to work out-of-process. Some of this isn't as important now, but we'd like to maintain compatibility for existing clients. -steve