Hi Marco, I am trying to follow your advice and use units instead:
const EXTERNAL_DEV_NONE : TGetExButtonStatesFunction = Pointer(0); However I am receiving an error: Error: Incompatible types: got "Pointer" expected "<procedure variable type of function(PCCDBS):LongInt;CDecl>" Please, can you shed some light on this? Best, R On Wed, Jun 14, 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: fpc isn't optimised for tail recursion, is it? > (Jean SUZINEAU) > 2. Re: Free Pascal bindings for EyeLink C code (with a > god-cast) (Rafael Pican?o) > 3. Re: Free Pascal bindings for EyeLink C code (with a > god-cast) (Marco van de Voort) > 4. Re: Non-initialized member access warning (Hairy Pixels) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 13 Jun 2023 15:25:59 +0200 > From: Jean SUZINEAU <jean.suzin...@wanadoo.fr> > To: fpc-pascal@lists.freepascal.org > Subject: Re: [fpc-pascal] fpc isn't optimised for tail recursion, is > it? > Message-ID: <310a7c2b-a874-b5d3-f80f-f49290358...@wanadoo.fr> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Le 12/06/2023 ? 19:05, Steve Litt via fpc-pascal a ?crit?: > > Busted! I used Pascal 1984-1993 > So I guess you are not familiar too with the "Result" variable which > appeared with Delphi 1 in 1995 if I remember correctly. > > nextt:= num; > > can be written to as : > > Result:= num; > > https://www.freepascal.org/docs-html/ref/refse94.html > > I prefer Result because it reduces risks of confusion with recursive call > and you can eventually take the address of Result with @Result (where > @nextt would take the address of the function nextt), > pass it by reference to another function ( e.g. FillChar( Result, > SizeOf(Result), 0); ) , > it behaves like a normal variable. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230613/5a2bb3c5/attachment-0001.htm > > > > ------------------------------ > > Message: 2 > Date: Tue, 13 Jun 2023 10:38:22 -0300 > From: Rafael Pican?o <cpicanc...@gmail.com> > To: fpc-pascal@lists.freepascal.org > Subject: Re: [fpc-pascal] Free Pascal bindings for EyeLink C code > (with a god-cast) > Message-ID: > <CAGpuCi5mjRLeCnMY= > mhrbm9kjf7r+brv6yrr3ydxt8njuht...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 > > ******************************************* > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230613/59aaf75a/attachment-0001.htm > > > > ------------------------------ > > Message: 3 > Date: Tue, 13 Jun 2023 15:48:36 +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: > <7e225875-c784-019a-1091-a89f612ef...@pascalprogramming.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > On 13-6-2023 15:38, Rafael Pican?o via fpc-pascal wrote: > > 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: > > > A matter of taste. I would have as less macros as possible. Moreover the > typed const doesn't require including additional files at the usage > site, so IMHO it is objectively a better solution > > > ------------------------------ > > Message: 4 > Date: Wed, 14 Jun 2023 13:50:34 +0700 > From: Hairy Pixels <generic...@gmail.com> > To: Sven Barth <pascaldra...@googlemail.com> > Cc: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org> > Subject: Re: [fpc-pascal] Non-initialized member access warning > Message-ID: <86575ba9-8fe9-4216-bca0-94991010f...@gmail.com> > Content-Type: text/plain; charset=us-ascii > > > > > On Jun 8, 2023, at 6:01 PM, Sven Barth <pascaldra...@googlemail.com> > wrote: > > > > Please report a bug with a complete example. > > Better late than never :) > > https://gitlab.com/freepascal.org/fpc/source/-/issues/40321 > > Regards, > Ryan Joseph > > > > ------------------------------ > > 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 15 > ******************************************* >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal