Leaderboard

Another more elaborate example that will show why is compiler strictness for var parameter necessary, and why without it we could easily and unintentionally write the code that can corrupt memory otherwise Pass the Dog, Get the Cat

Perhaps this will help: Magic behind FreeAndNil

What if you wanted an even smaller Lua integration for Delphi? Just using stock Lua 5.4.7+, statically linked directly into your Delphi executable with no external overhead, and automatic registration of native Delphi routines, all in a single unit? Introducing Chandra - Lua Scripting for Delphi. A client needed a tiny, simpler, but capable Lua scripting solution than my recently released PLUA. The Chandra.o file (just Lua compiled into a single translation unit) is linked directly into Delphi via {$L Chandra.o} with ~600kb overhead. It can directly register published Delphi class methods via RTTI. Enjoy, happy coding! 👀 https://github.com/tinyBigGAMES/Chandra

It is pretty simple - imagine if the code below would work that way: procedure ReplacePet(var pet: TPet); begin pet.Free; pet := TCat.Create; end; procedure Main; var dog: TDog; begin ReplacePet(dog); dog.Bark; // meow?! end; FreeAndNil is special because it just destroys and assigns nil. But a var parameter does not give that guarantee.

Save 25% on new registrations with coupon code BF2024! The latest version, DocInsight 2025 Insiders (Version 6.0.0.19), was released on November 24, 2025. DocInsight 2025 Release Notes (Draft) Download

I would be concerned... This sounds like you have something else causing trouble. It could be an indication of some corruption in your installation, or some other software that is causing the trouble. If things are working then no need to mess with it, but I would recommend using this as motivation to make sure you have a good backups of your data, so you will be ready if you need to create a fresh Windows install sometime soon.

New video - 3D in WebUI

Since Windows ARM can run x86 code, yes. Rosetta on Mac doesn't have anything to do with the above, as far as I know - that's just for whether Intel macOS apps would be able to run in the Mac host.

Parallels allows you to run Windows ARM VMs on M-series Macs

Please use coupon code BF2024. Valid until end of November. https://delphihtmlcomponents.com/order.html

Nevermind. I was testing with the --as flag. If I leave that out it works just fine.

For a long time I have always used the form "\\?\". It has some advantages (like bypass MAX_PATH limits and the name parsing). See here: https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#win32-file-namespaces Bye

I have 🙂 As I'm just starting the development of mobile apps, I would rather use the FMX native way, than jump right into a third party product which will add to the initial cost of the project. If I feel the need later though, it may be an option

Hello Everyone! I am an experienced Delphi Developer, currently available and exploring opportunities for full-time remote employment with a long-term commitment (via Upwork platform). If you have any openings, please feel free to contact me. https://www.linkedin.com/in/alexander-shyshko-1709992b1/ Primarily looking for full-time opportunities, but open to considering all options. I am flexible with time zones and can adjust my schedule to meet your needs. Thank you for your time.

Hi, thanks! At the moment, I'm only targeting Windows. Mostly because much of that audience is on Windows. I won't rule out other platforms, however. The products that I create are for clients using Windows. The libs are open source so if anyone wishes to port to other platforms, go for it. Note that often, a library may take express advantage of a feature that is limited or unique to the Windows platform, however. In the case of games for example, the last time I looked at the Steam stats, the vast majority of users there are still on Windows. It's no debate that Windows still has the best development tools, and it is still much easier to release on it. But, like I said, I'm not against it per say, just that for me, in the current moment, I have no need or desire to release anywhere else.

A word of advice - in C++, NEVER use the Form's OnCreate and OnDestroy events! (they are perfectly safe to use in Delphi only). The events are based on Delphi's object creation model (derived classes created before base classes), which is different than C++'s creation model (base classes created before derived classes). Also, their behavior has changed a few times over the years (due to internal changes [and bugs] related to handling of the TForm.OldCreateOrder property), so they are not always consistent in C++. As such, the events can be called before the Form's C++ constructor and after its destructor, respectively (I've seen it happen), which leads to undefined behavior in C++. In C++, ALWAYS use the Form's actual constructor/destructor instead.

I'll never understand people like you. Every project except CScript has a Requirements section where he mentions that Delphi 12.2+ is supported, or at least that it is made and tested with Delphi 12.2. You really should RTFM more often.

I agree with @Uwe Raabe As you state that the APIs may return structures that cross reference one another - a record would not be suitable here, unless you had pointer support. The record is normally defined as something with a fixed size, and as Uwe pointed out, the interdependence means this constraint would not be met. So you would either need a pointer to a record (a forward can be defined for that), or use classes (that we know are heap bound). If your codegen can do some analysis and identify which entities have interdependencies, you could choose to use records in one case and classes in another, but IMO, just having a single consistent approach will save you in the long run. I'd just go for using classes.

Here an example: program Crcr32Demo; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils, System.ZLib; var Buf1 : AnsiString; Buf2 : String; Crc : UInt32; begin Buf1 := 'Hello World!'; Crc := System.ZLib.Crc32(0, PByte(Buf1), Length(Buf1) * Sizeof(Buf1[1])); WriteLn('AnsiString ID=', IntToHex(Crc, 8)); Buf2 := 'Hello World!'; Crc := System.ZLib.Crc32(0, PByte(Buf2), Length(Buf2) * Sizeof(Buf2[1])); WriteLn('UnicodeString ID=', IntToHex(Crc, 8)); ReadLn; end. The output is: AnsiString ID=1C291CA3 UnicodeString ID=E2106423 AnsiString and Unicode string doesn't produce the same result because character code are different (8 bit and 16 bit per character). and CRC32 work at the byte level.

The TRecordA/TRecordB relation leads to a structure of infinite size. I would question the design choice, but having no knowledge of the underlying API that is not more than just a gut feeling. IMHO, you should use the approach that fits best. There is no general rule for all cases.

I disagree the use of pointers directly for a waste use. In the past I had some side effects not "beauty" ... especially if they were targeting structures with "managed types". In the state of Darian exposition, I will prefer the mix solution. CodGen projects are always "beasts", I wish you good luck in your job @Darian Miller

@Gex99 It's always nice to know that someone benefited from the work I put it in to solve a problem. It was a tricky problem that, as you saw from my posts, took a while to solve. The solution I eventually found was easy to implement. I'm glad it worked for you too. Thanks for saying something.

Thanx TOM F, your fix to run as invoker worked for me beautifully.

I ran a benchmark test and found that your implementation is much more performant than mine. Congratulations on the great work!

Internally we didn't agree on that sentence. Anyway a new guy start next week and another one in August. Many complain that there is no jobs for Delphi. At the same time some employers leave Delphi as it is hard to find developers. It don't make sense for me 😊