So in my last entry, I teased you with a hint that you can now work with COM using pure REALbasic code. Today, I'm going to tease you a bit more. ;-) Before you can understand how to write COM code from REALbasic, you must first understand the basics of COM. Otherwise, none of it will make any sense.
COM stands for Component Object Model, which is basically a fancy way of saying "generic object." REALbasic has its own object model, and C++ has an object model, as does C#, etc. What makes COM special is the fact that it is meant to be a generic object model that can be used from any language. So you can write a COM object in one language, and make use of it in another language. What makes this even more special is that these objects are to be backwards compatible, as well as forwards compatible. So if your application expects FoobarObject Version 1, then it will always get a FoobarObject Version 1 even if Version 3 is the latest version installed (or, if the system cannot get a Version 1 for some reason, then you get nil back instead).
The basic idea behind a COM object is that the programmer actually works with interfaces, not concrete classes. So, instead of getting a FoobarObject itself, you would get something which implements the IFoobarObject interface (COM interfaces generally start with "I").
Ok, now that you have had a crash course in what COM is an a bit about how COM is used, it's time to talk about the object model itself. Basically, how do you represent a COM object?
For a good technical discussion, Raymond Chen has a wonderful one here.
What this means in REALbasic parlance is that a COM object is a Ptr. The first field in that Ptr is another Ptr, which points to the VTable. The VTable is a series of Ptrs which are function pointers to the concrete class implementor's methods. It sounds scary, but it really isn't, I promise.
Next time, we'll take a real world example of how this all works in REALbasic.