Have you noticed that Visual Studio's Win32 dialog editor supports adding ActiveX controls? Right click on a dialog surface in a Win32 project, and "Insert ActiveX Control" is right there. But if you do that in a plain vanilla Win32 project, the control won't show up in runtime. Short of MFC or ATL, there is no built-in ActiveX containment logic for Win32 projects that I know of. Native COM is a great lightweight COM client helper, but no containment there. So, what would it take to host an ActiveX control?
Conceptually, not a lot. Typing wise, quite a bit. Kind of like matrix multiplication: straightforward but tedious. The minimal control creation flow is:- Create the control as a COM object
- Call its IOleObject::SetClientSite()
- Initialize the control (using IPersist*)
- Call its IOleObject::DoVerb, passing OLEIVERB_INPLACEACTIVATE
- IOleClientSite
- IOleInPlaceSite
- IOleWindow (its base)
- IOleControlSite
- IOleInPlaceFrame
- IOleInPlaceUIWindow (its base)
- IDispatch
That's why I went through the trouble of spelling out all that boilerplate into a convenience class. Even at the bare minimum of functionality, we are looking at 300+ lines. I've tested that class with a handful controls, both by Microsoft and not by Microsoft - most of them instantiate and render with no problem, and the ones that don't exhibit similar errors with other containers too.
All the site methods are implemented, but most of them are implemented trivially. All the methods that have out parameters are either implemented correctly or shorted out with an error response.
The class doesn't interact with the Win32 dialog editor. That said, the minimal set of parameters for control creation is - CLSID, parent window, coordinates. Spelling out those in code is not a big deal.
No comments:
Post a Comment