I have some MFC code (custom CWnd controls and some classes to expose) that I need to make into an activex / COM object with interfaces. Is it easier to make an ATL project with MFC support and make my ActiveX that way or make an MFC ActiveX control?
When doing an activeX control, is doing dual interfaces (like that explained in ACDual from microsoft) good/bad/makes no difference?
MFC is an easier route if you're a newbie in COM stuff: The wizards are better and more helpful. But it's far less flexible than ATL, which is probably not an issue if you simply have a couple of simpole interfaces to implement.
Also, IIRC MFC doesn't support dual interfaces. Dual interfaces are interesting in 2 cases: - Performance is an issue. Such as a call to a short method executed millions of times. - The object users are programmed in C++. Calling a native interface is way easier in C++ than calling an automation interface.
In conclusion, dual interfaces are cool but they are really interesting only if you can have them for free. Which means you use a framework which supports them. If you plan on much COM-based work, it's interesting to investigate in ATL and deeper COM knowledge. If you just have to provide a couple of simple MFC-based objects, just stick to MFC.
It's a bit of pain to use MFC for COM - there is too much code to write, macros to copy - however you have to know what you're doing if you are mixing MFC and ATL because they are deceptively similar yet different, especially if you create windows with ATL.
The main thing is, if you use MFC from an ATL, you will need to start every one of your ATL method with AFX_MANAGE_STATE(AfxGetStaticModuleState( )), otherwise you will get random problems. This is done for you automatically when you implement COM with MFC, which is why there are these ugly METHOD_MANAGE_STATE macros in every method.
Beyond this, it just works. MFC objects inside a ATL objects is what I do..
I've always used straight ATL with no MFC for development of COM components. MFC is useful as an application framework, which I generally didn't need for lightweight (non-UI) COM components. ATL provides lots of support for strings, collections, and various utility classes without the need to bring in all of MFC with the logistical complexities that arise from doing that (like setting context on every public API call, etc). It also includes some basic UI support via CWindow and its friends if you're building a UI component.