MFC COM or ATL COM (ActiveX)

I have MFC code (CWnd user controls and some classes for expansion) 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 this way or make an MFC ActiveX control?

When you do activeX control, do dual interfaces (e.g. explained in Microsoft's ACDual) good / bad / doesn't matter?

+4
source share
3 answers

MFC is an easier route if you are new to COM stuff: wizards are better and more useful. But it is much less flexible than ATL, which is probably not a problem if you just use a pair of simpole interfaces to implement.

In addition, IIRC MFC does not support two interfaces. Dual interfaces are interesting in two cases: - Performance is a problem. For example, a short method call is executed millions of times. - Users of objects are programmed in C ++. Invoking a native interface is easier in C ++ than invoking an automation interface.

In conclusion, the dual interfaces are cool, but they are really interesting only if you can download them for free. This means that you are using a framework that supports them. If you plan to work a lot on the basis of COM, it is interesting to explore in ATL and deeper knowledge of COM. If you just need to provide some simple MFC-based objects, just stick with MFC.

+1
source

It’s a little pain to use MFC for COM β€” there is too much code to write, macros to copy β€” however, you should know what you do if you mix MFC and ATL because they are deceptively similar, but different, especially if you create windows with ATL.

The main thing is if you use MFC from ATL, you will need to run each of your ATL methods with AFX_MANAGE_STATE (AfxGetStaticModuleState ()), otherwise you will get random problems. This is done for you automatically when you implement COM with MFC, so each method has these ugly macros METHOD_MANAGE_STATE.

Other than that, it just works. MFC objects inside ATL objects are what I do.

+1
source

I have always used direct ATL without MFC to develop COM components. MFC is useful as an application framework that I don't need at all for lightweight (non-UI) COM components. ATL provides a lot of support for strings, collections, and various utility classes without having to use all the MFCs with the logistical difficulties that result from this (for example, setting the context for each public API call, etc.). It also includes some basic user interface support through CWindow and her friends if you are creating a user interface component.

+1
source

All Articles