D6 and COM

"Chris Uppal" <[hidden email]> wrote in message
news:43d90bb5$0$87299$[hidden email]...
Problem is there is no way of knowing which target types are already wrapped
in the image. There is a namespace problem here in that the structures in
the library may well correspond to same named wrapper classes in the image,
but then again they may not. Unlike interfaces there is typically no GUID
associated with structures (although this is possible to achieve in IDL), so
one doesn't know whether the POINTL in the typelib is some private
structure, or the global Win32 structure of that name.  So unfortunately you
have to use your knowledge of the image (and the Win32 API in some cases) to
make the decision. Sometimes it doesn't hurt to regenerate the librarly
based on seeing what clashes and then looking to see if the clashing items
really are one and the same.

> Also, because I don't really understand the ActiveX wizard, I'm never
> confident
> that it's safe to change any except the most trivial of its proposed
> settings...

For the other settings I'd agree it is sensible to use the defaults, but the
list of types is something you can choose from. Of course if you need to use
one of the things you don't ask to generate, then you have a problem, but
you can always go back and generate it later.

Regards

Blair

[hidden email] wrote:
> Chris Uppal wrote:
> [snip]
>
> On to BSTR!
>

Clean D6 image. Use Active-X component wizard on TV3D65.dll to generate
boocoo code.
Doing AXTypeLibraryAnalyzer open: 'c:\tv3d_65\bin\tvb3d65.dll'. shows
that
a FUNCDESC(SetBetaKey(sBetaUser, sSerialKey)) has this IDL:

[id(0x00000014)]
HRESULT __stdcall SetBetaKey(
        [in]BSTR sBetaUser,
        [in]BSTR sSerialKey);

And in TV3D65ITVEngine class>>defineFunctions
defineFunction: #SetBetaKey:sSerialKey:
                        argumentTypes: 'bstr bstr';
is 20th in the list (hex 14).

The generated function looks like this:
TV3D65ITVEngine>>SetBetaKey: sBetaUser sSerialKey: sSerialKey
        "Private - Invoke the SetBetaKey() method of the COM object.

                HRESULT __stdcall SetBetaKey(
                        [in]BSTR sBetaUser,
                        [in]BSTR sSerialKey);"

        <virtual stdcall: hresult 14 bstr bstr>
        ^self invalidCall

I call it like this:

initialize
        "Private - Initialize the receiver"

        path := '\tv3dsdk\media\'.
        globals := TV3D65ITVGlobals new.
        tv3d := TV3D65ITVEngine new.
        inputEngine = TV3D65ITVInputEngine new.
        tv3d setBetaKey: 'dmacq' asUnicodeString  asBSTR
                sSerialKey: ' blah blah' asUnicodeString asBSTR.

This same username serial pair works in VB.Net (sssshhhh), and upon
inspection, both appear to be valid BSTRS (a BSTR('dmacq')), defined as
a null terminated Unicode string with the length prepended.

I read the part in the BSTR class comment about allocating the memory
using sysAllocCall and it appears to me that String>>asBSTR does just
that.

asBSTR
        "Answer the BSTR (AX Automation string) representation of the
receiver.
        This conversion will also work fine for UnicodeString."

        ^BSTR fromString: self

What am I doing wrong here?

Thanks.

Donald

PS I googled the newsgroup for bstr and license key before coming here.

Donald,

DUMB question: does VB escape \?  The key is probably just a GUID or
other other hex-like or alphanumeric mess, but I have at times had fun
trying to figure out whether a C jock was giving me escaped or
non-escaped text.

Have a good one,

Bill

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

Bill,
"Bill Schwab" <[hidden email]> wrote in message
news:drbrou$e86e$[hidden email]...
>
> DUMB question: does VB escape \?  The key is probably just a GUID or other
> other hex-like or alphanumeric mess, but I have at times had fun trying to
> figure out whether a C jock was giving me escaped or non-escaped text.

Refresh my memory as to what non/escaped text is. It has (thankfully) been
so long that I have clean forgotten.

2) I should have mentioned in my previous post that the VB.NET code
that -does- work uses a different DLL, one that I -cannot- run the type
analyzer on. I haven't yet found a .tlb file that corresponds to it.

Thanks to all of you for putting up with this.

Donald

PS Here's a link to something that is amusing even if it is apochryphal:

http://benjerry.middlebury.edu/~share/smalltalkX/english/overview/humor.html

Blair,

> Problem is there is no way of knowing which target types are already
> wrapped in the image. There is a namespace problem here in that the
> structures in the library may well correspond to same named wrapper
> classes in the image, but then again they may not.

Yes, I see your point.  Still, I think it would be better if there were some
indication that proposed classes were already defined in the image (and not in
the proposed package) so that we could be warned that there was something that
called for review.

> So unfortunately you have to use your knowledge of the image
> (and the Win32 API in some cases) to make the decision. Sometimes it
> doesn't hurt to regenerate the librarly based on seeing what clashes and
> then looking to see if the clashing items really are one and the same.

Ideally it would be nice to be able to preview the proposed changes before
actually installing them.  I can see that that is probably more work than its
worth, especially given that we can use the image to try changes and back-out
if they are not to our taste.

    -- chris

[hidden email] wrote:

> tv3d setBetaKey: 'dmacq' asUnicodeString  asBSTR
> sSerialKey: ' blah blah' asUnicodeString asBSTR.

What actually goes wrong ?  GPF ?  Error from TV ? BSOD ?

I know virtually nothing about BSTRs, but one speculation is that TV is
expecting to take ownership of the system memory managed by the two BSTRs.  If
so then it would be wrong for Dolphin to free that memory (which it will do
shortly after the call returns as the temporary BSTRs are finalised).

If this very uninformed speculation has any real validity, then I think you
should send #detach to them so that they know that they no longer "own" their
system memory.

    tv3d
        setBetaKey: 'dmacq' asBSTR detach
        sSerialKey: ' blah blah' asBSTR detach.

You may have to hand-edit the definition of #setBetaKey:sSerialKey: to accept
external addresses (or are they integers ?) instead of BSTRs.  If you do so
then take it out of the *auto-generated* category so that it won't be
overwritten if you re-generate the wrapper code.

    -- chris

Donald,

>>DUMB question: does VB escape \?  The key is probably just a GUID or other
>>other hex-like or alphanumeric mess, but I have at times had fun trying to
>>figure out whether a C jock was giving me escaped or non-escaped text.
>
>
> Refresh my memory as to what non/escaped text is. It has (thankfully) been
> so long that I have clean forgotten.

Assume I want to give you the string "Don's DLL is driving him nuts!"
but in Smalltalk.  Suddenly it looks like '"Don''s DLL is driving him
nuts!"' - that's what I mean by escaped.  In chunk format, the ! is
doubled/escaped too.

In C, \ begins various escape sequences, so C* programmers will often
reflexively write \\ for a single slash because their compiler will give
them what they intended.

It probably is not applicable, but if the license key contains anything
that VB escapes, you would have to ensure that your Smalltalk code
passes the same thing as the VB.  About the only way you could be fooled
by this is if the key were provided to you in the escaped form, which
seems unlikely.  Is the key just another long string of letters and
number, like an M$ CD key?


> 2) I should have mentioned in my previous post that the VB.NET code
> that -does- work uses a different DLL, one that I -cannot- run the type
> analyzer on. I haven't yet found a .tlb file that corresponds to it.

Can you get any information about it from OLE View or another tool?

Chris' point about ownership is well taken.  Since he suggests releasing
ownership, there is no harm in trying it to see if it fixes the problem;
if he is wrong, the worst you will suffer is one string stuck in memory
until you reboot - worth a try.

There is a concept of system/shared/something strings (anybody remember
what it's called?) that might be appropriate.


> Thanks to all of you for putting up with this.
>
> Donald
>
> PS Here's a link to something that is amusing even if it is apochryphal:
>
> http://benjerry.middlebury.edu/~share/smalltalkX/english/overview/humor.html 

:)  That reminds me of clsd post a long time ago where some poor sap was
arguing with Alan, clearly (painfully) oblivious to who he was.  I saved
it somewhere in my digital wasteland, so hopefully I will run across it
some day; good stuff, and quite authentic.

Have a good one,

Bill

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

Chris,

Chris Uppal wrote:

>
> What actually goes wrong ?  GPF ?  Error from TV ? BSOD ?

Just an error message and then no other 6.5 calls work.

I did get an answer to a post on the TV3D beta forum about whether the
keys were truly BSTRS. It turns out they look like this:

"The key is Unicode (each character is seperated with a Null) and
ending with Nulls;
followed by a constant Dword 8h and an additional empty Unicode.

Sample Hex (replace '1' with your key):

1010101010101010-01010101010101010-01010101010101010-01010101010101010008000
"

Not exactly a BSTR, eh?

I will try it and your detach suggestion when I get home.

Donald

Donald,

Very odd.  Call me suspicious, but it sounds like bollocks to me.

As an extra element of confusion to add to the mix.  I've just been checkng my
version (6.2) of this stuff, and looking at the single working example I have.
It seems that I followed the VC++6 tutorial code (e.g. Tutorial 2), and that
passes normal C strings to functions like Engine->SetSearchPath() and
Engine->SetDebugFile().  So I do the same in Dolphin, since Dolphin's ordinary
Strings are memory compatible with C strings.  I'm not sure why Dolphin doesn't
complain when I pass a String to an external method expecting a BSTR, but it
doesn't and everything seems to work fine.

On the other hand functions which get "string" data out from TV, such as
Engine-GetSearchPath(BSTR*), /do/ work with BSTRs.  Dolphin uses BSTRs for
those methods, and that all works OK too.

It sounds as if their IDL is completely up the Swanee...

On that basis, I'd expect to pass normal Strings to the licence key stuff too.
But what's happening with 6.5 is anyone's guess.  It might be worth asking: "If
I have a small VC++6 project, based on the supplied tutorials, which compiles
and works correctly with TV 6.2, what changes, if any, do I have to make to
re-compile and use it with TV 6.5 beta ?".

    -- chris

<[hidden email]> wrote in message
news:[hidden email]...
The conversions to UnicodeString and then BSTR are redundant. The VM
external call primitive will do that for you for a bstr argument type.

So what error do you get?

Regards

Blair

"Donald MacQueen" <[hidden email]> wrote in message
news:[hidden email]...
Is the VB code using it as an Active-X component? If so then it must have a
type-lib somewhere, probably bound into that DLL itself.

Regards

Blair

"Chris Uppal" <[hidden email]> wrote in message
news:43da0c54$1$87291$[hidden email]...
This should not be the case, unless the component is coded incorrectly, and
if it were I would not expect it to work with VB or VB.NET. The COM memory
management rules state that for an [in] parameter the caller is responsible
for memory allocation and freeing. If the callee wants to hold onto a copy
of the BSTR argument, it would have to copy it. The .NET runtime callable
wrapper generated for the Active-X component  by its type-library importer
will be expecting these rules, and so .NET will GC the BSTRs after the call
just as Dolphin would.

That said, your suggestion would only cause a memory leak of the two
strings, which wouldn't be the end of the world if Donald is only calling
this once.

Regards

Blair

"Chris Uppal" <[hidden email]> wrote in message
news:43da5ae7$1$87293$[hidden email]...
Because the VM will automatically convert them for you.

Regards

Blair

<[hidden email]> wrote in message
news:[hidden email]...
Donald, it looks to me like that might be the raw Unicode character data,
rather than the actual string you are expected to pass (i.e. the hex is the
character code point values, not a hex string).

Regards

Blair

(I seemed to have managed to respond to almost every posting in this thread
in less than 10 minutes, must be a record)

"Chris Uppal" <[hidden email]> wrote in message
news:43da0c54$0$87291$[hidden email]...
Yes, that's what I put in the defect report.

A perfectly reasonable idea, and quite achievable using RB Change Objects.
If you've used the rewrite tool in D6 you might have seen the browser it
brings up on the proposed changes which allows you to see the diffs that
will result. This could easily build on the same infrastructure kindly
provided by Refactory. My only reservation would be that the changes you get
to view would be a rather long list, so you might not be able to see the
wood for the trees. One more for the list though.

Regards

Blair

Blair,

> > Ideally it would be nice to be able to preview the proposed changes
> > before actually installing them.  I can see that that is probably more
> > work than its worth,
> > [...]
> A perfectly reasonable idea, and quite achievable [...]

That'll teach me not to second-guess what you'll consider feasible!

Oh, by the way, how are you getting on with re-writing the VM in Visual Basic ?
I'm looking forward to being able to generate DLLs ;-)


> My only reservation would be that the changes you
> get to view would be a rather long list, so you might not be able to see
> the wood for the trees.

Once you had filtered out the classes that didn't exist already, and the
methods that were identical to what already existed, I suspect the list of
proposed changes wouldn't be too unmanageable (and we'd be in some difficulty
if it was, with or without the ability to preview changes).

    -- chris

Blair McGlashan wrote:
>
> The conversions to UnicodeString and then BSTR are redundant. The VM
> external call primitive will do that for you for a bstr argument type.

RIght. I tried 'dmacq', and 'dmacq asUnicodeString, etc. I was grasping
at straws. ;-)
>
> So what error do you get?

I get a messageBox that says "beta verification fails".

So I downloaded a copy of VC++ Express and debugged a short demo
program that makes the same call -and- it works! Here is the info from
disassembly in the debugger. Any tips appreciated>

        pTV->SetDebugFile(strcat(srchpath, "\\debugfile.txt"));
0042EAC4  push        offset string "\\debugfile.txt" (486DA0h)
0042EAC9  lea         eax,[ebp-21Ch]
0042EACF  push        eax
0042EAD0  call        @ILT+1765(_strcat) (42C6EAh)
0042EAD5  add         esp,8
0042EAD8  mov         esi,esp
0042EADA  push        eax
0042EADB  mov         ecx,dword ptr [pTV (49773Ch)]
0042EAE1  call        dword ptr [__imp_CTVEngine::SetDebugFile
(49A53Ch)]
0042EAE7  cmp         esi,esp
0042EAE9  call        @ILT+3610(__RTC_CheckEsp) (42CE1Fh)

        // Set your beta-key/license:
        pTV->SetBetaKey("dmacq", "45860696-9232EB4C-191FA9CF-FC21BBA1");
0042EAEE  mov         esi,esp
0042EAF0  push        offset string
"45860696-9232EB4C-191FA9CF-FC21B"... (486D74h)
0042EAF5  push        offset string "dmacq" (486D6Ch)
0042EAFA  mov         ecx,dword ptr [pTV (49773Ch)]
0042EB00  call        dword ptr [__imp_CTVEngine::SetBetaKey (49A538h)]

0042EB06  cmp         esi,esp
0042EB08  call        @ILT+3610(__RTC_CheckEsp) (42CE1Fh)

        // After setting the beta-key/license its time to init the engine:
        pTV->Init3DWindowed(formHWND, true);
0042EB0D  mov         esi,esp
0042EB0F  push        1
0042EB11  mov         eax,dword ptr [formHWND (497730h)]
0042EB16  push        eax
0042EB17  mov         ecx,dword ptr [pTV (49773Ch)]
0042EB1D  call        dword ptr [__imp_CTVEngine::Init3DWindowed
(49A534h)]
0042EB23  cmp         esi,esp
0042EB25  call        @ILT+3610(__RTC_CheckEsp) (42CE1Fh)

And here is what happens in:

CTVEngine::SetBetaKey:
1002C9D0  mov         eax,dword ptr [esp+4]
1002C9D4  push        eax
1002C9D5  push        1028A230h
1002C9DA  call        1010EA30
1002C9DF  mov         ecx,dword ptr [esp+10h]
1002C9E3  push        ecx
1002C9E4  push        1028A130h
1002C9E9  call        1010EA30
1002C9EE  add         esp,10h
1002C9F1  mov         byte ptr ds:[1028A758h],1
1002C9F8  ret         8
1002C9FB  int         3
1002C9FC  int         3
1002C9FD  int         3
1002C9FE  int         3
1002C9FF  int         3

This is my Dolphin code that does not work:

path := '\tv3dsdk\media\'.
        globals := TV3D65ITVGlobals new.
        tv3d := TV3D65ITVEngine new.
        inputEngine = TV3D65ITVInputEngine new.
        tv3d setBetaKey: 'dmacq' sSerialKey:
'45860696-9232EB4C-191FA9CF-FC21BBA1'.

The strange thing is that the setLicenseKey call in 6.2, which also
uses bstrs, works fine. It is going at a different DLL.

Donald

Blair,

> Because the VM will automatically convert them for you.

Dear me!  How unnexpected.  Pretty cool...

    -- chris

<[hidden email]> wrote in message
news:[hidden email]...
This is not a COM call, its using an exported C++ member function, and not a
virtual function, so you are not comparing like with like here. I would
think this is because there is a direct C++ library you can use without
going through COM at all. Do you have a sample in VB6, or VB.NET/C# that
goes through the COM interface?

Regards

Blair