You might want to look at the actual output in a type library viewer like the Class Browser and compare to what a 'normal' COM server returns for numeric integer values.

My memory of Delphi is really fuzzy but if I remember correctly COM objects need to return specific COM types in Delphi in order to be converted to the proper type codes. VFP expects Variant type values I think and htis is were things may get hung up. If there is a type mismatch (which appears to be the problem) there's nothing you can really do about it short of fixing the COM server.

Christoph's approach of creating a wrapper object is a good workaround, but an expensive one in terms of having to include VB runtimes (actually you maybe able to get away with using the Windows Scripting Host to do this without requiring any VB Runtimes).

+++ Rick ---




>Hello Chris,
>
>thanks. The problem is a part of a well-known project and I'm trying to write a class to be later used in it. Fortunately I know the guy who wrote it in Delphi, but neither he nor I understand, what happens. The Rick's idea that the Delphi's long could be a 64-bit value, is not the case. The return value is a 32-Bit signed integer.
>
>What is still more irritating: I can call the methods of the COM-object without brackets as if they were properties:
>
>

>lServerOnline=oPC.GetServerOnlineState instead of
>lServerOnline=oPC.GetServerOnlineState(),
>

>and I still get this .Null. as result, but not an error!
>
>At the same time the "real" properties return "real" values.
>
>The way with VB is certainly a possibility, but I think the next try will be to ask the programmer to assign the results of methods to some special property so that I can read it from there.
>
>Alexander
>
>
>>Hi,
>>
>>>I have to work with a COM-Server (ProgID is ccpcatmlib.pcatmlib) written in Delphi. The Server works fine with Visual Basic, for example:
>>
>>If a COM server doesn't work with VFP, but works fine in VB, one workaround is to write a little helper object in VB. It would consist of one sub routine for each property or method that cannot be called from VFP. The routine receives a reference to the COM server using a generic object data type on the VB side to enforce late-binding, reads or writes the property and returns back the value.