COM MFC versus ATL way

I am at a point of deciding which way to move our system into the COM world. Many of the DLLs we have would lend themselves nicely to COM objects. At this juncture we require only an in-proc server implementation. COM wrapping our libraries the MFC way is quite straight forward. Since marshalling insn't an issue we do not have to change any method declarations. Under these conditions, I can not see if ATL would provide any benefits.
Any suggestions or recommendations are appreciated

[chris law]

If your dll's don't rely heavily on MFC (means if you can do without it with not too much work) you will have smaller executables (maybe a bit faster) and no dependency on other dll's. When you like to offer clients additional information (like HRESULTS) you are better off with ATL by far.
I like ATL.

G'things

chrislaw

[Masaaki]

Hi.

Beforehand, I have never written ActiveX control on the commercial
leverl.

I have read the article talking about the exact topic which you want
somewhere of MSDN help. But I forget where it is.
As you know, ATL has dll extension and ActiveX wizard has ocx extension. The most difference between them is a file size.
Even though Micorosoft published ActiveX control, web developer
focus more on Java applet partly because ActiveX downloading time
is larger than applet and its compatibility between IE and Netscape.
So, ATL is more target of Internet. However, Microsoft had have a
target, but fails.
As I read your question, Microsoft recommends that your company
keeps the current status of using ocx extension as long as I remeber
the MSDN article. Rewriting ActiveX control from ocx to dll is to waste time.
However, Microsoft will enhance ATL functionality more and may
leave ocx ActiveX control, I guess.

Regards.
-Masaaki Onishi-

Thanks for the info Chris.
Many of the DLLs are heavy on the MFC, many or which contain UI code. The non UI DLLs probably will never be interfaced with anything but their current C++ based UI components. Providing access to the core calculating algorithms to a VB client for example might have some merit.

If we eliminate MTS and DCOM from our current scenario, it looks like ATL doesn't provide any additional benefits.
If we do elect to go the ATL way I guess the best way to approach our customer interface for phase 1 of our conversion would be hand coding under IDL

[Dave Lorde]

Our development team have used both methods, and we now concentrate on ATL. I think that although ATL is aimed at creating small, lightweight components, it is a superior (from the programmer's POV) facility for implementing all kinds of COM components, even MFC in-process heavyweights (you can use MFC classes with ATL, no problem).

I'd recomend 'Beginning ATL COM' from Wrox Press as a good book for learning ATL.

Dave

Thanks all for the info.
I shall continue my study of "Beginning ATL COM"

[gmadn]

ATL is recommended for lightweight components. MFC makes the code bulky but provides a lot of useful wrappers.

ATL's implementation of callbacks is much better than MFC's. If your app has a lot of callbacks this may factor in your decision.

Do not assume that you do not need Marshalling just because you have an in-proc server. If your app is multithreaded and your components exists in different Appartments you may still need to marshall you data back and forth.