tcom - COM object implementation questions

[Jeff Godfrey]

I've used tcom several times in the past to access features/functions
within COM objects, but I've never used it to *create* a COM object.
Now, I have that requirement.

I know the tcom extension is documented to provide this ability, but I
have no experience with using it that way. Is there anyone with
experience in this area who could answer the following questions?

- Is tcom's documented ability to create Tcl-based COM objects stable /
functional?
- Is it possible to "wrap" a tcom-based COM object using TclApp and
still have a functional COM object?

Thanks for any input.

Jeff Godfrey

[Jeff Godfrey]

On 11/4/2010 1:27 PM, Jeff Godfrey wrote:

> - Is tcom's documented ability to create Tcl-based COM objects stable /
> functional?
> - Is it possible to "wrap" a tcom-based COM object using TclApp and
> still have a functional COM object?

Replying to my own post...

I have successfully created a simple, Tcl-based COM object by following
the sample project outlined in the tcom docs. So, that gets me over my
first hurdle (does it (still) work?)...

Now, I'm wondering about point #2 above. That is, can I wrap my code

using TclApp and still have a functional COM object?

I did notice the following statement in the tcom docs:

"The tcom server implementation depends on the Tcl package mechanism to
provide the code that implements specific COM interfaces."

What I'd like to do is create a stand-alone EXE (via TclApp) containing
my COM functionality and use it on a system without a Tcl installation.
Does anyone know if that's possible?

Thanks,

Jeff

[Harald Oehlmann]

On 8 Nov., 16:46, Jeff Godfrey <jeff_godf...@pobox.com> wrote:
> What I'd like to do is create a stand-alone EXE (via TclApp) containing
> my COM functionality and use it on a system without a Tcl installation.
> Does anyone know if that's possible?

As nobody answered for 4 days I will give it a try...

I think it should work without issues in a starpack/kit. I use it
regularly in client mode without issues.
The point to resolve is to register the Active X in the registry and
get the right exe started, when someone invokes methods.

TCOM is a quiet but very good extension. One reason is, that it is so
high quality.
I have observed, that the author corrects bugs very quickly and is
quiet an everything else.
Don't feel alone ;-)

Harald

[Jeff Godfrey]

On 11/8/2010 9:57 AM, Harald Oehlmann wrote:

> I think it should work without issues in a starpack/kit. I use it
> regularly in client mode without issues.

Harald,

Thanks for the input. I too have a number of (wrapped) applications the
use tcom in client mode - and it works extremely well. But, as I
mentioned, I've never tried to use it in COM server mode.

> The point to resolve is to register the Active X in the registry and
> get the right exe started, when someone invokes methods.

This is exactly the point I'm unclear on. The tcl-based tcom server
sample works exactly as expected on a tcl-aware system. I'm just unsure
of the COM registration mechanics outside of that environment.

> TCOM is a quiet but very good extension. One reason is, that it is so
> high quality.
> I have observed, that the author corrects bugs very quickly and is
> quiet an everything else.

Agreed.

Thanks again.

Jeff

[jgodfrey]

To round out this thread...

I recently traded a few emails with tcom's author (Chin Huang)
regarding this issue. Ultimately, using tcom to create a *wrapped*
COM object doesn't seem possible. I've included some excerpts from
our conversation below in case someone has further interest in the
details. Or, maybe someone has some ideas for making this work?

Thanks,

Jeff Godfrey

=====================================

-- Jeff to Chin --
1. Is it possible to create a wrapped COM object using TCOM?
2. Would you happen to have any specific guidance in this regard, or
have any example code?

-- Chin to Jeff --
The tcom COM server implementation starts up a Tcl interpreter for
each COM server, so I don't see how it can invoke the code in a
wrapped application. The Tcl command

::tcom::server register Banking.tlb

creates the Windows registry key

HKEY_CLASSES_ROOT\\CLSID\\$clsid\\tcom

with two values:

"TclDLL" contains the full path to the Tcl interpreter DLL to load.

"Script" contains Tcl code which the Tcl interpreter will execute to
load and register the Tcl implementation of that COM class. The
script is simply "package require Banking" because the Banking package
encapsulates the COM class implementation.

-- Jeff to Chin --
Not knowing much about it, it would seem that it might be possible to
modify the values stored in the 2 mentioned registry entries in order
to get COM to do the right thing in the face of a wrapped COM
object.

-- Chin to Jeff --
The COM server starts a Tcl interpreter and uses it to execute the Tcl
implementation of the COM class. Having never developed a wrapped
application, I don't know how the COM server Tcl interpreter can
access Tcl code residing inside a wrapped application.

-- Jeff to Chin --
Normally, in a wrapped application (starpack style), the application
EXE contains the Tcl-interp. That get's bootstrapped by the EXE init
process (details unknown to me) and then some "main" tcl procedure is
called to start the wrapped application. So, the Tcl-app and the Tcl-
interp are both in the wrapped EXE file.

So, on the surface it would seem that "TclDLL" would point to the
wrapped EXE itself and "Script" would point to the designated tcl
procedure within the wrapped EXE. That said, I'm sure the devil is in
the details and there are probably a number of stumbling blocks.

-- Chin to Jeff --
You're going to have trouble here. The COM server specifically wants
to load a DLL, not an EXE, containing the Tcl interpreter. It first
tries to load the DLL at the path specified by "TclDLL", and failing
that, tries to load the Tcl interpreter DLL installed by the
ActiveState ActiveTcl installer.

-- Jeff to Chin --
Understood - thanks. I guess I'll have to tackle this project
using .NET... :-(