COM in REALbasic

| | Comments (6)

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.


(your article seems a but truncated)
Stupid questions maybe; what are the differences between COM and OCX objects? From my days doing VB I remember the version h-ll with the OCX components...


There we go, I fixed the truncation issue. Thanks for pointing it out. As for COM vs OCX vs ActiveX, they're all speaking about the same technologies, really. COM is the superset of all of them.

COM is Windows only, correct?

Incorrect -- COM is a cross-platform concept. I know that it is used on the Mac (for things like IOKit, and Office Automation), and I wouldn't be too shocked to hear that there are uses for it on Linux. However, COM is definitely most prevelent on Windows and is heavily used there.

I wonder if the com would work for OpenOffice, which would make for nice cross platform use.

So theoretically, if the RB IDE implemented a COM interface some nice things could happen that have been available in VB for a long time. I'm thinking of things like in-IDE custom property editors, report designers and things like that.

Leave a comment