Debugging COM

[Intel_C_Intel]

If I have a COM call in FORTRAN that doesn't work, what can I do about it?
I have the same call working fine in VB, but in FORTRAN I get an 0x80004005 error (Rather unhelpfully, "Unspecified error"). Has anyone got any debugging tips?

[Intel_C_Intel]

Hi Dan,

Since it works from VB, you obviously understand how to call the method. My guess, then, is that the problem lies in the argument passing mechanism. As I mentioned in my reply to another note, VB has some mostly undocumented restrictions and ways of passing arguments in a COM call. The method may have been written to expect arguments the VB way, and no other way (even though other ways are reasonable and possible). So, your challenge is to try to figure out exactly what VB is doing, and emulate it. You could do that by writing a Fortran COM server with a method using the same IDL definition of the arguments,
write a VB test program to call it, and then set a breakpoint in the COM server to see exactly how VB is passing the arguments.

I hope this helps,
Leo

[Intel_C_Intel]

Leo,
Thanks for the reply. I'm actually calling methods on a third-party COM object. I used the Fortran module wizard to generate an interface module, and everything seemed to be going swimmingly. Then I came to this call that I couldn't get to work. I'm calling a method of a sub-object, but I think there must be something wrong with my object reference, as the method fails (I've used the same method calls in VB to create a similar set of objects). Are there any scoping problems I should be aware of in FORTRAN COM?

[Intel_C_Intel]

Hi Dan,

> Are there any scoping problems I should be aware of in FORTRAN COM?

There are no "scoping" problems. Using a sub-object in an object model should not work any differently than using the "top-level" object.

What is a common problem is making sure that you have the right interface to the object. For example, let's say you want to call a COM method of a dual interface on a sub-object. You call a method on a top-level object that returns an IDispatch* of the sub-object. If the method says that it returns IDispatch*, you can't assume that you have a pointer to the dual interface. You may in fact have a pointer to a Vtbl that implements only the IDispatch methods, and if you attempt to access one of the methods in the dual interface, you're off into "hyperspace"... The moral is, when in doubt, take the pointer you have and COMQueryInterface for the pointer you need. If you get back the same address, you already had it - but in my experience, often you don't...

Leo

[Intel_C_Intel]

Hi Leo,

Your suggestion sounds promising, but I'm not sure how to use COMQueryInterface: Would this be an appropriate usage to check I have the correct interface:

 
CALL COMQueryInterface(oStream, IID_IStrm, oStream, status) 

If it is correct, I still have problems - beacuse that doesn't work! :o)

[Intel_C_Intel]

> CALL COMQueryInterface(oStream, IID_IStrm, oStream, status)

> If it is correct, I still have problems - beacuse that doesn't work! :o)

That looksOK - if the status is 0, then it would seem that you have the correct interface.

Leo

[Intel_C_Intel]

Leo, just to bring you up to date with this. I contacted the author's of the COM object in question, but they couldn't make the code work either (never having tried it in FORTRAN). Thery are still investigating, but suggested:

It would appear that there are problems, which may be due to the COM implementation  
within CVF, when using methods of the interface which themselves return an  
interface pointer.

Are there any known problems in this area?

[Intel_C_Intel]

> Are there any known problems in this area?

No. You can see that working in the AdvancedCOM samples such as AUTODICE, DLINES, and DSBUILD.

Leo