Re: Stupid tcl/tcom newbie question

From: Chris Owens (when_government_fears_the_people_at_hotmail.com)
Date: 04/16/04 

Date: 15 Apr 2004 15:33:16 -0700

I found this old message which seems to indicate what I am trying at
least can be done:

--- Message begin ---

From: Chin Huang (cthuang@vex.net)
Subject: Re: Pointer to variant in tcom
 
  
View this article only
Newsgroups: comp.lang.tcl
Date: 2001-12-15 08:57:17 PST
 

In article <3C1AC02C.A23BFBFD@paradise.net.nz>,
Phil Haynes <phil.haynes@paradise.net.nz> wrote:
>Does anybody know how to make tcom pass a pointer to a variant when
>invoking a COM method ?
>
>Specifically, I am trying to access the DataStage ( a Data Warehouse
>data extraction tool) API
>
>I can get a handle to an interface called IDSJob and want to compile
an
>opened job.
>
>IDSJob has a method CompileJob( Path, Reason )
>Path [out] BSTR* Path to failing job component if job is invalid
>Reason [out] BSTR* Reason for failure

For each parameter with the [out] attribute, pass the name of a Tcl
variable as the argument when invoking the method. After the method
returns, the Tcl variables will contain the output values.

--- Message end ---

Amusingly, Excel's COM interface does not appear to have any methods
with an out parameter! So I can't test my code on Excel.

I have noticed another oddity. The example I am basing my tests on
has an unused procedure to list all methods of a given COM interface.
When I run it on the Excel interface, I get things like this:

method 383 VOID SendKeys {
        {in VARIANT Keys}
        {in VARIANT Wait}
}

method 485 {Sheets *} Sheets {
}

method 1061 BOOL DisplayFullScreen {
}

method 1809 BSTR DecimalSeparator {
}

But when I run the procedure on our COM interface, I get things like
this:

method 1 ERROR GetProjectName {
        {out {BSTR *} pbstrProjName}
}

method 4 ERROR RunAll {
}

This seems to indicate that tcom (or someone in the chain) is unable
to determine what type of value ought to be returned from these
methods. However, my script is not complaining about the overall
return value; just about that 'out' parameter.

So maybe the ERROR message doesn't matter. Maybe our uncommon use of
'out' parameters is part of some bletcherous hack that is related in
some way.

After a brief conversation with one of the fellows who is writing the
COM object, he has pointed me to an Excel script that successfully
communicates with the COM object. So, I will go look at the Excel
script for a little while, and see if that does anything for me.

Hmm. Annoyingly, the Excel script works great.

It contains the following procedures:

Sub Load DLLComp()
        Set SLLcomp = GetObject(, "MyAppName.Application")
End Sub

Sub GetProjectName()
        Dim name As String
        Dim val As Long
        Dim retval As Variant
        retval = Dllcomp.GetProjectName(name)
        Range("D6").Select
        Selection.Value = name
End Sub

Perhaps my next steps should be:
1) trying every data type tcl has, to see if I can read in SOMETHING.
2) Trying another method (perhaps one with only an 'in' parameter
type) to see if it works
3) One thing my coworker pointed out to me is that our COM server
presents multiple interfaces, two of which are very similar. I will
spend a bit of time trying to understand what that means, and if it is
related to my problem.

Chris Owens
San Carlos, CA