Thank you Marco, I am elaborating on top of your suggestions.
> The problem is that the logical solution, making it a macro, doesn't
work, as macro definitions don't export through USES clauses.
I think that pre-processor constants with $I would be a valid alternative
for using the best solution. For example:
// constants.pp
____
{$MACRO ON}
{$ifndef EXTERNAL_DEV_NONE}
{$DEFINE EXTERNAL_DEV_NONE := TGetExButtonStatesFunction(Pointer(0))}
{$endif}
{$ifndef EXTERNAL_DEV_CEDRUS}
{$DEFINE EXTERNAL_DEV_CEDRUS := TGetExButtonStatesFunction(Pointer(1))}
{$endif}
{$ifndef EXTERNAL_DEV_SYS_KEYBOARD}
{$DEFINE EXTERNAL_DEV_SYS_KEYBOARD :=
TGetExButtonStatesFunction(Pointer(2))}
{$endif}
____
program godcastsucks;
{$I constants}
type
PCCDBS = ^TCCDBS;
TCCDBS = record
userdata: Pointer;
buttons: array[0..255] of AnsiChar;
internal: Pointer;
end;
TGetExButtonStatesFunction = function (accdbs: PCCDBS): Int32; cdecl;
function enable_external_calibration_device(
buttonStatesfcn: Pointer {other arguments removed for simplicity}):
Int32; cdecl;
var
Statesfcn : TGetExButtonStatesFunction;
begin
Result := Int32(TGetExButtonStatesFunction(@buttonStatesfcn^));
case Result of
0 : { do nothing };
else
begin
Statesfcn := TGetExButtonStatesFunction(buttonStatesfcn);
Statesfcn(nil);
Result := -1;
end;
end;
end;
function ExButtonStatesFunction(accdbs: PCCDBS): Int32; cdecl;
begin
WriteLn('God casts sucks');
end;
begin
WriteLn(enable_external_calibration_device(EXTERNAL_DEV_NONE));
WriteLn(enable_external_calibration_device(@ExButtonStatesFunction));
ReadLn;
end.
____
> Note that an alternative for this macro exists since FPC 3.2.0:
Thank you for the reference!
On Tue, Jun 13, 2023 at 7:00 AM <fpc-pascal-requ...@lists.freepascal.org>
wrote:
> Send fpc-pascal mailing list submissions to
> fpc-pascal@lists.freepascal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> or, via email, send a message with subject or body 'help' to
> fpc-pascal-requ...@lists.freepascal.org
>
> You can reach the person managing the list at
> fpc-pascal-ow...@lists.freepascal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of fpc-pascal digest..."
>
>
> Today's Topics:
>
> 1. Re: Free Pascal bindings for EyeLink C code (with a
> god-cast) (Marco van de Voort)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 13 Jun 2023 11:25:13 +0200
> From: Marco van de Voort <f...@pascalprogramming.org>
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] Free Pascal bindings for EyeLink C code
> (with a god-cast)
> Message-ID:
> <5a5a8eac-e91d-d9d7-4131-d7301ec3c...@pascalprogramming.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
> On 13-6-2023 05:19, Rafael Pican?o via fpc-pascal wrote:
> > (1) I have no idea on how to translate these god-casts, eg.,
> > ((getExButtonStates)0), to free pascal. Right now, I think that even
> > if I don't really need them, I just want?to understand and learn
> > in?the?process.
>
> The problem is that the logical solution, making it a macro, doesn't
> work, as macro definitions don't export through USES clauses.
>
> Defining it a proper constant would be the best solution, but FPC
> doesn't like it :
>
> const
>
> ?EXTERNAL_DEV_NONE = TGetExButtonStatesFunction(pointer(0));
>
> so the next best is turning it into a type constant at the expense of
> sizeof(pointer) bytes in the binary:
>
> const
>
> ? EXTERNAL_DEV_NONE : TGetExButtonStatesFunction= pointer(0);
>
> etc etc.
>
> >
> > (2) So, the whole point here is?binding the
> > "enable_external_calibration_device" function. It expects a
> > "getExButtonStates buttonStatesfcn". Can you check if my current
> > binding is right?
> >
> A purist would say it needs to be "ansichar" rather than char (because
> in future unicode modes char could be 2-byte, for the rest it seems ok.
>
> > (3) I am using the?ELCALLTYPE?macro just because?they were?using them
> > too,?I am assuming backward compatibility. But I am not sure if I
> > really need them. EyeLink code depends on custom SDL2 headers and I
> > am?running SDL2 Free Pascal related stuff just fine (and it has cdecl
> > in everything). What do you think about that? For reference, this is
> > the macro:
> >
> You must match the calling convention of the implementation. Some
> functions have target dependent calling conventions, some non native
> libraries force cdecl even on Windows. (where stdcall or fastcall is
> more conventional)
>
> Note that an alternative for this macro exists since FPC 3.2.0:
>
>
> https://wiki.freepascal.org/FPC_New_Features_3.2.0#Support_for_WinAPI_directive
>
> Even though the naming is not "elegant" for crossplatform usage.
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
> ------------------------------
>
> End of fpc-pascal Digest, Vol 228, Issue 14
> *******************************************
>
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
