Fw: AsciiZ confusion

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Fw: AsciiZ confusion

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

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

>
> ==========================
> 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
>
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
>
> ---
> avast! Antivirus: Inbound message clean.
> Virus Database (VPS): 0635-3, 08/31/2006
> Tested on: 8/31/2006 1:52:02 PM
> avast! - copyright (c) 1988-2006 ALWIL Software.
> http://www.avast.com
>
>
>



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



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: AsciiZ confusion

Matt Emson
>> 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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: AsciiZ confusion

afpTeam

----- Original Message -----
From: "Matt Emson" <[hidden email]>
To: "afpTeam" <[hidden email]>; "FPC-Pascal users discussions"
<[hidden email]>
Sent: Thursday, August 31, 2006 2:57 PM
Subject: Re: [fpc-pascal] AsciiZ confusion


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

The Delphi program is a canned application which makes provision for a stub
DLL, such as I wrote.  I have no access to the Delphi app's core
functionality.  The PB DLL is an externalized DLL as only part of the PB
program.  Therefore, the only way I know to share data between the two, is
to talk to the Stub DLL from a scripting engine within the Delphi program.
The Delphi App's authors create the calling conventions, i.e. all varients
from within the Delphi program, so again, I'm forced to use them.

The real question I guess, is whether I should be able to pass AsciiZ
directly through the DLL as I indicated, given the Varients are first set to
ascii strings, then asciiZ, then back to ascii strings as they return back
into Delphi, or will this level of type changing confuse FPC at runtime?

AFP



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



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal