First of all.....I'm a newbie and I'm trying to take my programming skills
to the next level.

I want to learn about COM, but finding it difficult to understand in a real
world situation.......basically I learn by looking at examples....Well could
someone help me in this goal.

I think the program I've describe below will help me grasp the COM concept:

1.  I want to create a SERVER using com that will accept a tBitmap as a
incoming object.

2.  I want to create a Client that will send a TBitmap as a outgoing Object.
The Tbitmap could be a TMemoryStream.

If I see this example maybe I would understand com better........thanks for
answering such a newbie question.

pbri...@bellatlantic.net

[..]

Don't feel rained on, "P."  COM is difficult to understand, not because
the concept behind it is hard, but because Microsoft is genetically
incapable of explaining a simple concept using simple words.

COM is based on the one essential idea of allowing public definitions of
"objects," such that every program, programming language, and the
operating system itself knows about them and can work with them.  COM
uses a wide variety of technologies in its implementation but hides them
behind a consistent view of the world.  DCOM (Distributed COM) extends
the model to multi-computer situations while trying to maintain the
same, consistent view.

COM "servers" are the things which actually implement the objects --
unbeknownst to the "clients" who merely use the objects without knowing
or caring how they work.  Servers can be DLL-libraries, which will be
opened and maintained by COM itself, or they can be applications, which
are also started and ended by COM itself.

COM has been known by various monikers over the years, including OLE,
OLE Automation, Automation, ActiveX, and ... "what do you want to call
it today?"  All of these are "essentially the same" as COM, certainly
from a concept point of view.

And, it does work and does work well.  Especially now that we have fast
CPU's because Microsoft did their usual efficient job on the code.  But
one very nice thing about the COM protocol is that, because COM itself
is responsible for coordinating the object activities and for
transferring both control and data between client and server, both the
client and the server can ignore many issues that would cause machine
dependency or slow execution.  As COM is changed in various releases,
every client and server improves (or un-improves) with it.  A two-edged
sword to be sure, but at least it's consistent.

What Microsoft simply cannot do is to recognize that programmers don't
want to know the dirty details in two volumes of unreadable
overly-technical manuals.  Of course, Visual C++ people have little
choice in the matter.  (MFC is unusable in that respect.)  But we
enlightened Delphi folks ;-) have a simple and straightforward view of
all this due to Delphi's excellent built-in support for it.

For examples, start first with Delphi's own example files.  Read the
source-code and I think a lot of things will quickly become clearer for
you.  The essential concept behind COM really is a simple one.

------------------------------------------------------------------------
Sundial Services :: Scottsdale, AZ (USA) :: (480) 946-8259
mailto:i...@sundialservices.com  (PGP public key available.)

Thank you! from one who purchased and read the standard discussions and the
help.  The simple concepts are the hardest to extract from Jingo-fied TLA's
scrambled by MS marketing.  Abjure obfuscation!!!!!!