Hi,

Sorry this is a long message, but hard to explain. I have a DLL I wrote in FreePascal 2.0.2, which is communicating between a Delphi program and a PowerBasic Dll, like follows...

PBdll exports PBSub ByRef as AsciiZ MyFreePascall_DLL DelphiDLLstubByRef_Variants

As noted, the Delphi Program integrates a DLL stub which forces me to make calls using it's pre-defined "Variants Only" format.

The problem comes when I pass data into FPC via "parameters" byRef through a procedure, into the PowerBasic DLL. The first parameter returns unmodified and the second parameter returns only one character wide, as if FPC is trying to receive back a pointer only, to the string space where the PB data resides. Or possibly it's just garbage and looks this way.

The FPC DLL is setup as follows:
============================

{$LONGSTRINGS ON}
library DelphiXchg;
uses Variants, strings;
//Declare PowerBasic external (a sub or function call, made no difference)
procedure subXchngAsciiZ(Data1, DATA2:string)stdcall;external 'PB.DLL';
//Declare the Delphi calling stub DLL (variants only);
function Delphstub(var vD1,vD2:variant):variant;stdcall;export;
//at runtime, Delphi sends in... vD1:='test'; vD2:='  '; // (vD2 is
place-held with a 'space')
begin
    if vD1 = 'test'                                    // vD1 is being sent
from Delphi
        then subXchngAsciiZ(vD1, vD2);  // call out to PB DLL
                                                            // vD1 should
come back 'tested'
                                                            // vD2 should
come back 'good'
end;
exports
Delphstub;        // FPC Return value unused
begin
end.

==========================
When the Delphi calling program sends in the variant vD1:='test', (through FPC to the PB DLL), FPC only gets back 'test' unmodified and variant vD2 is coming back as 'g', (only the first character, instead of 'good', (ahhh but vD2 did get modified at least)).

I thought that zero or null terminated AsciiZ data would handle the string array length automatically in FPC, on < 255 wide, but now I'm supposing I may have to break the variants out, use explicit calls internally by typed pointer reference and then reload the outgoing variants with the result data from the pointers to the explicit variables before returning, but I've had no success in figuring out how to set that up correctly.

Should it really be that much handling to pass AsciiZ on Variant types as parameters, or am I overlooking something stupid simple? The only example I have to go by is a VB program that makes calls directly across to PB, using ByRef ASCIIZ, so the problem seems mostly from being forced to use the Variant types in parameters from the Delphi calling program.

Thanks for any ideas.

AFP

---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0635-3, 08/31/2006
Tested on: 8/31/2006 1:49:00 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

Let me remove some comments....(sorry)

 {$LONGSTRINGS ON}
library DelphiXchg;
uses Variants, strings;
 //Declare PowerBasic external
procedure subXchngAsciiZ(Data1, DATA2:string)stdcall;external 'PB.DLL';
//Declare the Delphi calling stub (variants only);
function Delphstub(var vD1,vD2:variant):variant;stdcall;export;
begin
    if vD1 = 'test' then subXchngAsciiZ(vD1, vD2);
exports
Delphstub;        //unused
begin
end.

---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0635-3, 08/31/2006
Tested on: 8/31/2006 2:01:58 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com

> As noted, the Delphi Program integrates a DLL stub which forces me to > make calls using it's pre-defined "Variants Only" format.

I'm not clear why you need to have a FPC DLL between a PB DLL and Delphi... this part makes no sense.

If you need to, dynamically load the DLL. If you are exporting params compatible with FPC, they should also be compatible with Delphi.

M

----- Original Message -----