Question

I am writing a native COM/Ole/ActiveX wrapper for a scripting language.
I need some advices to implement events/callback (like onreadystatechange from Microsoft.XMLHTTP object)

I noticed that some COM objects can call my custom object through an IDispatch interface. Is it the only way to manage events ?

Answer 1

If you’re asking the more general question about how COM events work (from any client, not just IE which has some specific requirements around security, etc.) and how to expose your objects’ events, then there’s a good CodeProject article, Understanding COM Event Handling, which has lots of details about how COM event handling works. Plus a C++ sample (which doesn’t depend on ATL or MFC) to illustrate how to host events. Warning: this is a pretty complicated article, but if you can get through it and understand it, you’ll have a good background on how COM events work.

If you’re specfically asking how to expose your COM objects into javascript so they can be called from Internet Explorer, then how to create an activex control that fires events to javascript (without using ATL) is a good blog post that discusses exactly what you need to (as the title suggests) expose your COM objects to javascript, including all the IE-specific goo.

BTW, unless you have a good reason not to, I’d suggest using ATL to handle your COM support, exposing your events, etc. You can do it in plain, no-dependency C++ (as the article above does) but ATL makes things easier. A reasonable starting point is MSDN’s ATL Events section, but I’d definitely read the CodeProject article first for some general background info before diving into the MSDN stuff.

Answering your specific question about IDispatch and events: events don’t have to use IDispatch, and clients can talk directly to your C++ event-handler implementation. But most if you want your events to be handled by IE, by javascript, by VB6, and other automation-only apps (“automation” is the COM term for clients using only IDispatch to call properties, methods, and events on COM objects). Most event-sending apps, for this reason, use what are called “dual interfaces” which (in their C++ implementation) inherit from both IDispatch and your custom events interface, and end up calling the same code under the covers. ATL makes it really easy to build such a dual-interface COM component.