PtrInt is used two places in dbf.pas for typecasting to a pointer, but in dbf_common.pas it is defined as LongInt. I have changed it (at least locally) to
PING. Anybody with rights to make edits, who care to fix this? I have just tested and my application still breaks in the same place as 3 years ago, unless I make the edit listed in my first post.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had this in the back of my mind since you "pinged". I coincidentally just committed r820 for a different reason, which is similar. Does it take care of your issue?
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I download a snapshot, it still contains "Tokyo" for file \packages\Delphi104\tdbf.dpk.
It is only \packages\Delphi104\dcltdbf.dpk, which has the "Sydney" text.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
https://sourceforge.net/projects/tdbf/
Click "code"
Click "download snapshot"
That gives me a zip file: tdbf-code-r843-trunk.zip
Inside that zip file the tdbf.dpk for delphi 10.4 is from 24-8-2020
dbf.pas is from 3-3-2023
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For some reason, I cannot see earlier comments in this discussion, so I don't know where I made the mistake, but I do now see what you are referring to.
Does r845 fix it for you?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PtrInt is used two places in dbf.pas for typecasting to a pointer, but in dbf_common.pas it is defined as LongInt. I have changed it (at least locally) to
{$ifdef Delphi_XE}
PtrInt = NativeInt;
{$else}
PtrInt = Longint;
{$endif}
It looks like it fixes the bug here, but has such a bug really been there for a long time?
Any comments?
In the lazarus version this was fixed long ago
I've encountered a similar issue that I've detailed here. I think your suggested fix should work.
See answer in the thread referenced above.
Is it possible to actually fix it in this non-lazarus version ? So future users can download a version, where it has been changed.
PING. Anybody with rights to make edits, who care to fix this? I have just tested and my application still breaks in the same place as 3 years ago, unless I make the edit listed in my first post.
I had this in the back of my mind since you "pinged". I coincidentally just committed r820 for a different reason, which is similar. Does it take care of your issue?
Yes, it does, thank you.
It is in its essence the same fix.
I also notice runtime packages in 10.4 carry the name Tokyo. It should be Sydney.
Can you be more specific? I see a
tdbf\packages\Delphi104folder. I don't know where you see "Tokyo".Inside \packages\delphi104\tdbf.dpk file.
It is correct (
{$DESCRIPTION 'TDbf for Delphi 10.4 Sydney'}) in revision 843.Last edit: Paul Baker 2023-03-20
If I download a snapshot, it still contains "Tokyo" for file \packages\Delphi104\tdbf.dpk.
It is only \packages\Delphi104\dcltdbf.dpk, which has the "Sydney" text.
What exactly were you steps for "downloading a snapshot"? I think you're looking at old code.
https://sourceforge.net/projects/tdbf/
Click "code"
Click "download snapshot"
That gives me a zip file: tdbf-code-r843-trunk.zip
Inside that zip file the tdbf.dpk for delphi 10.4 is from 24-8-2020
dbf.pas is from 3-3-2023
For some reason, I cannot see earlier comments in this discussion, so I don't know where I made the mistake, but I do now see what you are referring to.
Does r845 fix it for you?
Yes, it is fixed now.