D6 and COM

First, to Andy and Blair: great job on D6. Very nice, and fast too, I
especially like the source control. Using Envy on my day job has
spoiled me terribly, and I like it.

Second, I have been banging my head against the wall trying to talk
through COM to a 3d library, which is written in C++, with mixed
results.  Some of the functions work fine and other gpf. The latter
seen to be mostly those that send bstrs and those that return an
sdword. I suspect that the interface specs I am using are not quite
right, but it is hard to tell.

The discussion forums they have talk about "unmanaged" C++ code and C++
with ATL. I have googled both of these terms but have not been able to
figure out what they mean. Could some kind soul please enlighten me so
that I can eliminate them from my possible problems. Any other tips on
debugging COM appreciated.

Thanks.

Donald

Donald,

> Second, I have been banging my head against the wall trying to talk
> through COM to a 3d library, which is written in C++, with mixed
> results.  Some of the functions work fine and other gpf. The latter
> seen to be mostly those that send bstrs and those that return an
> sdword. I suspect that the interface specs I am using are not quite
> right, but it is hard to tell.

Not just related to COM, I have been very impressed at how errors in
return type can cause ugly crashes.  That's not to say that it is
unexpected, but it did surprise me.

Also, are you sure of sdword vs. hresult?  If something is errantly
labeled as an hresult, Dolphin will interpret some numbers as errors.
Put another way, is the gpf really that (probably) or is it a different
error generated by Dolphin?

Finally, it is possible that all is well but that the component code
crashes if the calling sequence is not correct.  For example, after
creating an object, you might need to initialize it before calling the
problematic methods.

You might also think about whether the code expects to be embedded in
some kind of COM container.  Some calls might lead to ugliness if the
environment is not correct??  Searching Blair's posts with COM, activex,
control, visual, site, etc. might turn up some useful information.


> The discussion forums they have talk about "unmanaged" C++ code and C++
> with ATL. I have googled both of these terms but have not been able to
> figure out what they mean.

I associate (perhaps incorrectly) managed/unmanaged code with .NET.


 > Could some kind soul please enlighten me so
> that I can eliminate them from my possible problems. Any other tips on
> debugging COM appreciated.

Do you have a type library?


Have a good one,

Bill


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

Donald,

> The discussion forums they have talk about "unmanaged" C++ code and C++
> with ATL. I have googled both of these terms but have not been able to
> figure out what they mean.

My understanding is that managed implies garbage-collected as provided by
the .net environment. Therefore, managed C++ is C++.net and unmanaged C++ is
normal C++ (uses new and delete).

John

Bill Schwab wrote:
This is the method that blows up:

GetPosition: pRet
        "Private - Invoke the GetPosition() method of the COM object.

                HRESULT __stdcall GetPosition(
                        [out, retval]TV_3DVECTOR* pRet);"

        <virtual stdcall: hresult 49 TV3D65TV_3DVECTOR*>
        ^self invalidCall

ExternalStructure subclass: #TV3D65TV_3DVECTOR holds x, y, and z as
bytes:
z
        "Answer the receiver's z field as a Smalltalk object."

        ^(bytes floatAtOffset: 8)

The error I get is "Object variable or With block variable not set
(Error 91)" which is a VB error described here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbenlr98/html/vamsgobjnotset.asp


>
> Finally, it is possible that all is well but that the component code
> crashes if the calling sequence is not correct.  For example, after
> creating an object, you might need to initialize it before calling the
> problematic methods.

Agreed. Here is the calling method:
getPosition
        "Answer the <TV3D65TV_3DVECTOR> result of invoking the GetPosition()
method of the COM object."

        | answer |
        answer := (TV3D65TV_3DVECTOR new).
        self GetPosition: answer.
        ^answer asObject

>  Searching Blair's posts with COM, activex,
> control, visual, site, etc. might turn up some useful information.

ok. will do.
>
>
> Do you have a type library?

Yes. Any (non-obscene) suggestions as to what I should do with it?

Donald

John Keenan wrote:
Thanks. John. That makes sense.

Donald,

Reading below, I see that you have answered these questions.  I will
leave them here just in case it is somehow helpful.

How do you call the offending method?  Is there a wrapper?  You will
will certainly need to create (naturally) and quite probably initialize
[*] the structure before the call.

Apologies if this old news for you, but note that Dolphin typically
tries to pass things by reference "on its own".  In other words, do not
send #yourAddress to the vector; Dolphin will take care of that.  Ditto
for your b-strings.

[*] not that you _should_ have to do so in this case




Did you create this, or did the type library analyzer write it?  Sadly,
you might need to expliclicitly set it to some value.

What happens if you inspect TV3D65TV_3DVECTOR new?  I would expect bytes
to be an all-zero byte array of the correct size, which would reasonably
correspond to the origin, but somebody else might see it differently.



Putting up with VB error messages is more obscene than anything I could
suggest :)  I'm assuming you ran it through the type library analyzer.
If not, you should do so (after backing up the results of your hard work).

So far, I guess the first thing I would try is setting the vector to
1,1,1 prior to the virtual call, just to see if that puts a gag on the
error.

Have a good one,

Bill

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

Bill Schwab wrote:
> Donald,
>

> > getPosition
> > "Answer the <TV3D65TV_3DVECTOR> result of invoking the GetPosition()
> > method of the COM object."
> >
> > | answer |
> > answer := (TV3D65TV_3DVECTOR new).
> > self GetPosition: answer.
> > ^answer asObject
>

Both the above methods were generated by Dolphin using the Active-X
Component Wizard on the TV3d.dll.


> >>
> >>Do you have a type library?
> >
> >
> > Yes. Any (non-obscene) suggestions as to what I should do with it?
>
> Putting up with VB error messages is more obscene than anything I could
> suggest :)  I'm assuming you ran it through the type library analyzer.
> If not, you should do so (after backing up the results of your hard work).

Not sure what you mean here by "ran it through the type library
analyzer". I did Register Type library on TV3d.lib and got
"HRESULT Error: Error Loading type library/DLL. (FACILITY_DISPATCH)"
>
> So far, I guess the first thing I would try is setting the vector to
> 1,1,1 prior to the virtual call, just to see if that puts a gag on the
> error.
>
ok. I will give that a whirl.

Thanks for your help.

Donald

[hidden email] wrote:

> > Do you have a type library?
>
> Yes. Any (non-obscene) suggestions as to what I should do with it?

If you mean you have an IDL definition of the COM objects' interfaces, then it
might be worth checking that the definition there of the specific GetPosition()
function is the same as the one that Dolphin has discovered in the (supposedly
equivalent) data embedded in the DLL.  Otherwise you've already done all you
can do with it when the ActiveX wizard generated the wrapper classes.

Have you used the earlier versions of TV3D with Dolphin ?  If so, and if
the GetPosition() wrappers work OK with that, then maybe the problem is in the
6.5 version of TV3D (which is only a beta as far as I can see).

Do all versions of the #GetPosition: method fail, or is it just one of the ten
or so that are generated for that library ?  If so, which one ?

FWIW, I've played a little bit with a D6-generated wrapper for the 6.2 version
of TrueVision and at least one version, TVMesh>>GetPosition:, works OK.

    -- chris

Chris Uppal wrote:
As I understand it, a typelib such as tv3d.lib contains the binary
descriptions of the IDL, right?

Are you suggesting that these binary descriptions are correct, and what
Dolphin discovered in the DLL are not?

How in the world could they be different? I thought they were both
genereated from the C++ code in the DLL. Sheesh.

What should I use to inspect the typeLib?

>
> Have you used the earlier versions of TV3D with Dolphin ?  If so, and if
> the GetPosition() wrappers work OK with that, then maybe the problem is in the
> 6.5 version of TV3D (which is only a beta as far as I can see).

It is in the 6.2 version of TV3D that getPosition fails. I will go back
and compare the IDL to what Dolphin created, and also try Bill's
suggestion of filling the ExternalStructure (DX3VECTOR or whatever)
with 0's.

The problem with the beta is that my beta key will not work from
Dolphin. It does work from VB.net. But there is evidently a difference
in how VB handles BSTRS structures and how C++ handles them. IIRC, VB
sends strings and receives Unicode, and C++ both sends and receives
Unicode strings. This is probably the first problem I need to solve,
because the beta is much faster, and, they say, better.

Also in the beta, they now have two different DLLs. I am using the C++
one since that would seem to have the largest chance of being truly COM
compliant.  I also can't get anybody on their community boards to tell
me how to do straight COM, not COM through VB or COM with ATL, etc.,
even though they say it is possible Very frustrating.
>
> Do all versions of the #GetPosition: method fail, or is it just one of the ten
> or so that are generated for that library ?  If so, which one ?

This is the one that fails in 6.2:

GetPosition: pRet
        "Private - Invoke the GetPosition() method of the COM object.


                HRESULT __stdcall GetPosition(
                        [out, retval]TV_3DVECTOR* pRet);"


        <virtual stdcall: hresult 49 TV3D65TV_3DVECTOR*>
        ^self invalidCall


getPosition is what I call from my code; it allocates the DX3VECTOR (or
whatever) and then calls GetPosition. Dolphin generated two similarly
named methods for each TV3D call, one uppercase and one lower.. All the
ones I tried that aloocated and then returned DX3VECTOR failed with
error 91.
>
> FWIW, I've played a little bit with a D6-generated wrapper for the 6.2 version
> of TrueVision and at least one version, TVMesh>>GetPosition:, works OK.

Are you saying you call TVMesh>>GetPosition: and not
TVMesh>>getPosition:? I will try that.

Thanks for the tips.
>
>     -- chris

Donald,

> As I understand it, a typelib such as tv3d.lib contains the binary
> descriptions of the IDL, right?

Yes.  They are either compiled from IDL using MIDL (which I have done),
or I believe one can construct them programmatically; don't bet the farm
on the latter.


> Are you suggesting that these binary descriptions are correct, and what
> Dolphin discovered in the DLL are not?
>
> How in the world could they be different? I thought they were both
> genereated from the C++ code in the DLL. Sheesh.

Not necessarily.  They could have separately written the IDL and
header/source files.  They probably used something like the MS class
wizard that writes IDL and creates stubs for the C*, but that is not
required, or they might have edited the code after generating it.

Blair has commented on limitations of VB in relation to type libraries.
  Check the archives for the details.  Something about signed/unsigned
integers????  I think it came up in the context of a type library for
the win32 api.  It might be worth checking to see if it could be hurting
you.


> What should I use to inspect the typeLib?

Look for #printIDLOn: or #printIDL.  You might need to send it to "the
object's" #typeInfo.  It's one of those things that I do far enough
apart to have to rediscover it each time.  There might be a more magical
way to do it that I have not discovered.  IIRC, the analyzer has a
button for it, but I tend not to use the analyzer as a browser - maybe
I'm missing out???


> The problem with the beta is that my beta key will not work from
> Dolphin. It does work from VB.net.

That might be licensing???  In your shoes, I would search the archives
to see if Blair has written anything on instantiating or debugging
loading of a licensed control.


 > But there is evidently a difference
> in how VB handles BSTRS structures and how C++ handles them. IIRC, VB
> sends strings and receives Unicode, and C++ both sends and receives
> Unicode strings. This is probably the first problem I need to solve,
> because the beta is much faster, and, they say, better.

I would hope that close inspection of the IDL would reveal any such
differences.  With that said, I suppose if one sent character string in
a "unicode" buffer, it might be ok as long as the callee recognized (or
also made) the mistake.


> Also in the beta, they now have two different DLLs. I am using the C++
> one since that would seem to have the largest chance of being truly COM
> compliant.  I also can't get anybody on their community boards to tell
> me how to do straight COM, not COM through VB or COM with ATL, etc.,
> even though they say it is possible Very frustrating.

Just a possibility: they might not know what you mean or how to do it.
Much of the detail is just that; reference counting is a little more
frightening.  Smart pointers help, but I could see how they might lead
to developers who feel hobbled w/o their favorite wrapper.

Dolphin's COM interfacing is as simple to use as it is powerful; Blair
really nailed it.  The C* jocks arguably have to face a mix of the class
side initialization and the finalization behavior of the various
IUnknown classes on every call, not to mention allocating and
deallocating memory as in the wrappers, etc.

Have a good one,

Bill


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

Bill Schwab wrote:
> Donald,
>
[snip]

I find it hard to believe that IDL files could be out of sync with the
DLL. Actually, on second thought, I don't.  Serious idiocy is quite
possilbe in c*.
>

[snip]
>
> Dolphin's COM interfacing is as simple to use as it is powerful; Blair
> really nailed it.

I agree, and nothing I have said is intended to disparage Dophin's COM
handling. I have suspected from the beginning some kind of interface
mismatch on TV3d's part. I just did not know where to look. If I can
get some kind of info to feed these guys (hey look at this!), I might
get some reasonable answers and (maybe) make some progress.

Thanks for the help.


Donald

Donald,

> [snip]
>
> I find it hard to believe that IDL files could be out of sync with the
> DLL. Actually, on second thought, I don't.  Serious idiocy is quite
> possilbe in c*.

In this case, it's not just C*; it's binary components working against
you.  This dovetails with why I cringe every time somebody says "gee,
let me make this software project simpler by breaking it up into binary
pieces!".  Modules have boundaries, boundaries require interfaces;
sounds a lot like details, and we all know who hangs out there ;)

My point is simply that something that allows your Smalltalk to call
into somebody else's Cobol code is going to be a little on the
complicated side.  C* adds to the madness, but the real problem is the
contracts that enable the kind of interoperability you seek.


I can relate.  Over the summer, I was up against very similar kinds of
errors that were simply due to undocumented dependencies on the order of
calls, and more than a few undocumented noops.  It's quite frustrating
to reverse engineer something like this, especially when the developers
deny problems with things that you can eventually prove to be broken all
along.

Good luck!!

Bill

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

Chris Uppal wrote:
[snip]
>
> FWIW, I've played a little bit with a D6-generated wrapper for the 6.2 version
> of TrueVision and at least one version, TVMesh>>GetPosition:, works OK.

I got getPosition: to work in 6.2 by creating a class method on
DxVBLibAD3DVECTOR  that initializes its byteArray to zeros. The default
creates a DxVBLibAD3DVECTOR with an empty byteArray. The typeLib says
that getPosition: wants an array of floats in and out.

Progress! Woohoo!

On to BSTR!

Donald

Donald,

> Are you suggesting that these binary descriptions are correct, and what
> Dolphin discovered in the DLL are not?
>
> How in the world could they be different? I thought they were both
> genereated from the C++ code in the DLL. Sheesh.
>
> What should I use to inspect the typeLib?

All I had in mind was that the various representations of what /should/ be the
same information might have got out of step with each other.  Those things do
happen; anyone can make a mistake, especially with a complex build system
(which I bet TV have), and even more so during a product beta.  If you'd had
the IDL (human readable -ish) hanging around then it might have been worth
spending 5 minutes doing a quick check.  Not worth worrying about otherwise --
or only as a last resort.


> The problem with the beta is that my beta key will not work from
> Dolphin. It does work from VB.net. But there is evidently a difference
> in how VB handles BSTRS structures and how C++ handles them. IIRC, VB
> sends strings and receives Unicode, and C++ both sends and receives
> Unicode strings. This is probably the first problem I need to solve,
> because the beta is much faster, and, they say, better.

Hmm.  Are you using the wrapper code generated from the 6.5 beta libraries to
drive the 6.2 DLL ?  There may be problems with that if either you refer to
interfaces which are new in 6.5 or if TV have changed the existing interfaces
(which they should not have done -- very, very, naughty).  I ask in particular
because:

none of the eight generated #GetPosition: methods in /my/ version has index 49
(in the second to last line).  Which class is this method defined against ? I
asked before, it may be important.  If you are calling a function which does
not exist then you can expect a GPF (if you're lucky).

> I also can't get anybody on their community boards to tell
> me how to do straight COM, not COM through VB or COM with ATL, etc.,
> even though they say it is possible Very frustrating.

*Sympathy*


[from a later post]

> I got getPosition: to work in 6.2 by creating a class method on
> DxVBLibAD3DVECTOR  that initializes its byteArray to zeros. The default
> creates a DxVBLibAD3DVECTOR with an empty byteArray. The typeLib says
> that getPosition: wants an array of floats in and out.

Ah!  That sounds as if DxVBLibAD3DVECTOR has been generated implicitly by the
wizard as a side-effect of wrapping the TV stuff.  I saw the same thing if I
remember correctly.  What I did (which may not be optimal but it was easy) was
to generate a wrapper package for Dx8 directly.  That generates /loads/ of
stuff which you don't need, but what the hell...   It took a bit of messing to
get it right so here are the steps I followed (I have VS.Net 2003 on this
machine, I don't know if that's a prerequisite for the following).  First
ensure that you are working in a throwaway image (because we are going to trash
it).  Use the wizard to generate a wrapper package for 'Direct X 8 for Visual
Base Type Library'.  (I imagine that earlier versions of Direct X would work
just as well because we are only really interested in a few common
definitions).  That will create a package call DxVBLibA (answer "no" whenever
it asks if you want to move an existing class into the new package).  It will
also have added several methods called #libraryAndIndex to the class side of
pre-existing system classes, and as a result there will be circular
dependencies that prevent you saving the package.  I think they were added to
LOGFONT, PALETTENTRY, POINTL and RECT. Find these methods and either delete
them or change them to answer nil.  You should now be able to regenerate the TV
classes (I don't know whether you'll actually /need/ to, but that's what I
did).  You should now be able to save the packages, and exit the image without
saving.

BTW, one word of warning.  There are a lot of methods in the DxVBLibA package
where the wrapper wizard generates incorrect wrapping code.  I reported this
problem about two years ago (and possibly other people have too), but the
problem is still present in Dolphin 6. See

http://groups.google.co.uk/group/comp.lang.smalltalk.dolphin/browse_frm/thread/59e55561c21dd57b/d95f7bbdd09e30a7

for details, or look in the archives for my post dated 2004-01-08 entitled
'Active X Wrapper Generation'.  I don't think that bug is connected with the
problems you are seeing, but it might affect you in future.

    -- chris

Chris,

Chris Uppal wrote:
> Donald,
>
 > Hmm.  Are you using the wrapper code generated from the 6.5 beta
libraries to
> drive the 6.2 DLL ?

No. I am using 6.2 wrappers to talk to the 6.2 DLL. The code I posted
below is wrong; it is from 6.5. My bad.

Yes. Doplhin is generating the wrapper for DxVBLibAD3DVECTOR from TV3d.
The wrapper method getPosition:
creates DxVBLibAD3DVECTOR  but leaves its byetArray empty. Setting the
byteArray to zeros fixes the problem.
I am at work right now, but that sounds like a good idea. I will try it
when I get home.
Thanks.

Donald

Donald

<[hidden email]> wrote in message
news:[hidden email]...
> ...
> Both the above methods were generated by Dolphin using the Active-X
> Component Wizard on the TV3d.dll.
>

In which case you have already used the type library.

> ...
> Not sure what you mean here by "ran it through the type library
> analyzer". I did Register Type library on TV3d.lib and got
> "HRESULT Error: Error Loading type library/DLL. (FACILITY_DISPATCH)"

That's probably a library for either static linking, or linking against the
DLL, its not the type library. This will either have a .tlb extension, or
(more likely) be bound into one of the component DLLs.

Regards

Blair

"Chris Uppal" <[hidden email]> wrote in message
news:43d8b78b$1$87298$[hidden email]...
To avoid this problem it is best to deselect those structures from the list
before you press the Generate button.

Its a pretty obscure case caused by the use of in-out parameters. In this
case you might just as well use the basic method since no useful wrapper can
be generated. I don't think this issue was ever recorded, which is why it
hasn't been addressed to date.

Regards

Blair

<[hidden email]> wrote in message
news:[hidden email]...
> ...
> Yes. Doplhin is generating the wrapper for DxVBLibAD3DVECTOR from TV3d.
> The wrapper method getPosition:
> creates DxVBLibAD3DVECTOR  but leaves its byetArray empty. Setting the
> byteArray to zeros fixes the problem.
>

Donald, this will only happen if Dolphin has generated the structure
indirectly because it is a pre-requisite for the stuff you asked it to
generate, but is not one of the types you explicitly asked it to generate.
This can happen when the typelib cross references a type from another type
library. Only a stub class is generated implicitly - there are times when
you don't want an explosion of classes generated (which might be the case if
that implicitly referenced type references further types), but equally it
might be useful if this behaviour was optional so we'll look at that for a
future release.

Regards

Blair

Blair,

> >  It will also have added several methods called #libraryAndIndex to the
> > class side of pre-existing system classes[...]
>
> To avoid this problem it is best to deselect those structures from the
> list before you press the Generate button.

Problem is that there's no indication which target classes already exist in the
image.  (Or not that I can see).

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...

    -- chris

Blair,

> but equally
> it might be useful if this behaviour was optional so we'll look at that
> for a future release.

While we're talking about enhancements to the wizard (or backing classes), I'd
like to ask for a couple of minor cosmetic enhancements.

One is to change the labelling/positioning of the buttons.  Just about every
time I use the wizard, I make the same mistake.  Select a library to import.
Press [Next] to select the target package, etc.  Press [Next] to choose which
classes to create wrappers for.  Press [Finish] to complete the job.  :-(
Then curse and start again, this time remembering that [Finish] == [Cancel] and
that I have to press the [Generate] button...  Possibly you could add another
page, so that the [Next] button (possibly named [Generate] or [Finish]) would
generate the wrapper and take us to a final page that simply confirmed that
things had worked, warned of any problems ("See Transcript for details"), and
that sort of thing.

The other is that the "do you want to move <some class> into <some package>?"
questions get a bit annoying.  It would be nice if it could remember that I
don't want to move, say, RECT, and not ask again.  Also, it would be nice to
have yes-to-all and no-to-all options (or would that be too dangerous?).

    -- chris