Getting started with COM - ActiveX

Hi,

I'd need some help getting started with COM - ActiveX under Dolphin.

I need to import data from an Excel sheet into my Dolphin app.

I have no MS Windows Environment Programming background, and only a
faint idea about what COM is, ActiveX still means nothing to me. (I've
only been programming WebApps under Linux for a couple of years).

So far I'm actually doing some progress using Dolphin, but when it comes
to the above (COM and ActiveX) I'm lost, inparticularly  in connection
with Dolphin.

Could anybody point me to a site (for Dummies)about COM and ActiveX?

Thanks

Günther

On Wed, 08 Dec 2004 16:30:32 +0100, Guenther Schmidt <[hidden email]>  
wrote:

There is an example for Excel (writing to, I believe) in the class  
AXTypeLibraryAnalyzer. Look in the class side methods.

--
Regards
HweeBoon
MotionObj

Guenther,

>> Could anybody point me to a site (for Dummies)about COM and ActiveX?
>
> There is an example for Excel (writing to, I believe) in the class  
> AXTypeLibraryAnalyzer. Look in the class side methods.

In dealing with Word and Excel, I prefer to skip the type library
analyzer step and just let IDispatch do its magic, helped by some
hand-written wrappers.  Typically, one needs only a relatively few
methods, and can skip what the MS IDL will force Dolphin to generate.
The result is also much easier to navigate.  See my Word Automation
package to see what I have in mind.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Dear Bill,

thanks for this, I'll check on it once I've found out what ActiveX *is*.

As I said  ym background isn't MS Apps, it's WebApps on Linux hosts.

Maybe you could recommend a book or a site on the subject?



Günther




Bill Schwab wrote:

Guenther,

> thanks for this, I'll check on it once I've found out what ActiveX *is*.

First, let's cut through the smoke screen.  ActiveX as a "technology" (I
fear another buzzword is in the making - it will be a dark day when we
lose this one) is marketing hype.  Worse, it was an attempt by MS to
find cover for the fact that their binary components were native code
and essentially unsecurable vs. Java's sandbox concept.  Does that make
me a Java fan?  No, but it was fairly obvious what MS was doing.  You
say, "come'on Bill, you're just bashing Microsoft again".  Fair enough,
but wait until one of your controls won't script, and see what you have
to do to fix it.

An ActiveX component is really just about any COM component.  They are a
successor to OCX controls, which were also COM components, with _lots_
of functionality that most controls do not need.  Cutting out the
optional protocol allowed smaller components (competing with Java was
again a little difficult).  Now, just about anything that understands
IUnknown is called an ActiveX component.

So what's COM?  It is a standard for communicating between binary
components, potentially across process and even machine (though I
strongly urge that when you see DCOM, run, fast!) boundaries.  It is a
world of components, interfaces (think C++ vtables, though not tied to
any specific language), and reference counting.  Dolphin's mapping of it
is a thing of beauty.


> As I said  ym background isn't MS Apps, it's WebApps on Linux hosts.
>
> Maybe you could recommend a book or a site on the subject?

Rogerson's Inside COM.  Look for my newCOMer package (very old but
should still teach you something).

With all of that said, to drive Excel to do a few things, pick up my
Word Automation package, and start doing the logical thing to get Excel
going.  Ask questions here to get started.  For the most part, you will
not really need to understand the details.  It's kinda the way I rebuild
carburetors :)

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:cp7bnn$guc$[hidden email]...
As a contrary viewpoint we at Object Arts would strongly recommend you
generate the wrappers. We always generate wrapper libraries for the COM
components we use. As we use them we tend to augment these with additional
methods that make for a smoother Smalltalk integration, or which add extra
convenience, but in many cases this is not necessary. In fact if you are a
beginner we would strongly recommend you avoid IDispatch as you will be
working much closer to the COM metal. Generating and using the wrappers has
many advantages:
1) You can explore the object model using the normal Smalltalk browsers.
Apart from being more productive than reading the documentation, this fits
normal Smalltalk working style. Having constructed or partially constructed
your program you can browse senders and implementors in the normal tools. If
you do need to refer to the documentation, then you can easily relate the
generated Smalltalk classes to the COM interfaces in the documentation.
2) IDispatch is entirely late bound and is at least one, perhaps two, orders
of magnitude slower than calling through an early bound interface in
Dolphin. Generated interface classes will use early binding if it is
available. If it is not they will still use prebound dispatch ids to avoid
the cost of runtime name lookup.
3) Debugging is more difficult with IDispatch as you lose a lot of the
context that the names of the generated classes, etc, provide you with.
4) It is not always easy to construct the correct parameters for a late
bound call via IDispatch. The AX Component wizard knows how marshal between
COM types and Smalltalk objects, so if you use the "high-level" wrapper
methods you don't have to worry about this except in rare circumstances.

You should be aware that generating the object models for some large
applications like Word, or Excel, or Internet Explorer, can result in the
creation of literally megabytes of code. Frankly this doesn't matter at
development time - you can ignore the classes you don't use, just as you
ignore large parts of the Smalltalk class library most of the time. It
doesn't really matter at runtime either, since Dolphin's deployment
technology will successfully remove any of the generated classes that you
are not using. In fact you don't need to generate wrappers for the whole
object model anyway - just selectively generate interfaces as you need them.
The wizard may generate extra classes if you do this, but these will just be
empty stubs.

Regards

Blair

Blair,

True, but the IDL (in the case of Office) is so, well, bad, that as good
as the type library analyzer is, the result is not at all helpful.
Further, the extraneous/unwanted parts interfere with understanding.


> 2) IDispatch is entirely late bound and is at least one, perhaps two, orders
> of magnitude slower than calling through an early bound interface in
> Dolphin. Generated interface classes will use early binding if it is
> available. If it is not they will still use prebound dispatch ids to avoid
> the cost of runtime name lookup.

That would be relevant in dealing with small components, but with
Office?  When the command is "print this document", speed of binding is
irrelevant, IMHO.


> 3) Debugging is more difficult with IDispatch as you lose a lot of the
> context that the names of the generated classes, etc, provide you with.

The hard part is figuring out which parameters to pass, and in which
order to call the methods.  I saw nothing in the generated wrappers that
would assist with that effort.  That is not a failing of your work,
which I greatly appreciate and respect; it is a result of the IDL that
goes into it.


> 4) It is not always easy to construct the correct parameters for a late
> bound call via IDispatch. The AX Component wizard knows how marshal between
> COM types and Smalltalk objects, so if you use the "high-level" wrapper
> methods you don't have to worry about this except in rare circumstances.
>
> You should be aware that generating the object models for some large
> applications like Word, or Excel, or Internet Explorer, can result in the
> creation of literally megabytes of code. Frankly this doesn't matter at
> development time

I can't ignore the bloated image and change log that results from it.
If the wrappers actually helped me, I might feel differently.  As it is,
I see nothing but negatives in the case of the Office IDL.  On
everything else I have seen, I'm in full agreement with you.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]