How to get started with ATL/OCX

[N85iE3v7]

Hi,

I usually create DLLs and Windows low level applications. I have never had to create an ATL. However, right now I have to write a library.

In fact I have everything almost done, as this ATL must use a DLL and a class I wrote to interface it. This DLL implements a protocol whose physical media is either USB or Serial port, but it does not matter, I have the interface class that does all the thing, I only need to create this ATL.

How do I get started ?

Thanks!
Daniel

[modoran]

ATL = Active Template Library
You don't "need to create this ATL" as it is a library developed by Microsoft to help developers creating mostly COM/ActiveX applications.

ATL only comes with Visual Studio, payed versions only. Express Editions does not came with ATL.

Hpwever, as you are writing "Windows low level applications" until now you could write your COM server without using ATL, using only winapi :)

[webJose]

If you are an expert C++ coder, consider Don Box's book Essential COM: http://www.amazon.com/Essential-COM-Don-Box/dp/0201634465 .

It explains amazingly well, and it doesn't use ATL at all. Pure C++ plus the Windows COM API.

[freddie1]

Your terminology is somewhat unclear zlogdan. At least I'm confused. Here is what it sounds like to me. You have created code (in the form of a c++ class in a dll) that does something useful regarding serial ports or COM ports. However, you wish to translate it to a COM object rather than a standard dll that exports the class. Good idea. Then your code's functionality will be useful to any language user. In that case your options are as described above by modoran and webJose. You can take the Atl route, which are templates that supposedly make COM programming easier. Personally, I have just about every book on Atl ever written, and I've studied them all, but I don't use Atl. The biggest thing I've gotten out of Atl books is that they always have a lot of chapters explaining COM, with lots of non Atl examples. Andrew W. Troelsen's book "Developer's Workshop To COM and ATL 3.0" is particularly good in that regard. Writting the objects low level in C or PowerBASIC is what I usually do. It took me a very, very long time though to learn how to do that. I'm talking years, really. So you might want to think about that. It might be worthwhile to give the Atl route a shot though, and see if it works for you. Its full of typical Microsoft Wizards and such. And I will say it produces very compact code. That is why Microsoft created it. COM dlls created with MFC had the overhead of requiring the megabyte sized MFC42.dll, whereas Atl dlls were tight.

One other thing I might mention - I have never been able to successfully create in process COM objects with GNU MinGW, which is the compiler I prefer to use. Maybe its just incompetance on my part, but believe me - I've tried. The problem concerns module definition files and the required COM export DllGetClassObject. You didn't state which compiler you were using, but I thought I'd mention that. For creating in process COM objects I use either Viosual Studio or PowerBASIC.

[modoran]

@freddie, to create in-process COM servers (like Windows Explorers context menu handlers for example) you need to also use MIDL compiler which is not yet ported to MinGW.

VLC has an ActiveX control written in pure C compiled with GCC, but to create the typelib even they use Microsoft MIDL compiler.
COM dlls created with MFC had the overhead of requiring the megabyte sized MFC42.dll, whereas Atl dlls were tight.

Every windows version since XP has MFC42.dll included, so it is not a problem. However, almost nobody uses Visual Studio 6.0 these days, latest version of MFC library (MFC100.DLL) has 4 MB in size, without VC++ redistributable.

[freddie1]

Hi modoran!

I have no problems with using Microsoft's midl. I simply wanted to compile the COM object with MinGW. I was looking to get a smaller Dll. In general I've always found that MinGW creates tighter code. In any case, neither a typelib created by midl nor the *.h interface headers it produces are an absolute necessity for a COM object.

The problem I had concerned use of *.def files with MinGW. I spent about two solid weeks trying to crack this puzzle several years ago, and at this point the full details kind of escape me, and I simply don't have the time or inclination right now to revisit this issue. But at that time I was looking for help anywhere I could find it; I posted here; at Daniweb; the CodeBlocks website; everywhere but at the MinGW site which for whatever reason was completely 'down' at the time. I couldn't find anyone who could help me, but all the research I did on the various components of the MinGW compiler toolchain led me to believe what I was attempting to do was possible. I just simply couldn't figure it out. That's why I made the statement I made above about my 'incompetance'. That's why I'm not surprised that someone else managed to do it as you described (VLC, whatever that is).

While I'm not interested in persuing the matter again at this time, if I decide to do so in the future perhaps I can contact you about it as you seem knowledgible in that area. I appreciate your comment.