Der schöne Günther

IList<T> supports IArrayAccess<T>. Here's an example: procedure p(); type TRecord = record number: Byte; end; begin const items = TCollections.CreateList<TRecord>(); var item := Default(TRecord); item.number := 42; items.add(item); // Replace item at index 0 with a new one var newItem := items[0]; Inc(newItem.number); items[0] := newItem; WriteLn(items[0].number); // or use IArrayAccess<T> var arrayAccess: IArrayAccess<TRecord>; Assert( Supports(items, IArrayAccess<TRecord>, arrayAccess) ); Inc(arrayAccess.Items[0].number); WriteLn(items[0].number); end;

I was curious about the HTML-Writer. Your github repo (https://github.com/DeveloppeurPascal/HTML-Writer) links to https://htmlwriter.olfsoftware.fr which then links back to the Github page. Your Github repo readme says The "visit the software website" just links back to the very same github page as well.

Thanks, I didn't know that. I still have to support Windows 7, so I can't use it. Still, good to know.

It's specific to Windows, but I am just reading the registry from HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones for all the timezones and offsets.

My experience is from a long time ago (around 2016), so things might have changed completely (hopefully for the better). All in all, it was disastrous. It was supposed to be some kind of dashboard / remote control app for industrial production lines. It had to be presented at an exhibition. There were numerous problems I never really got behind, and which each change, I felt more and more helpless because of extremely limiting debugging and analysis capabilities. Battery consumption was inexplicably high We used the TeeChart Pro library for some graphical displays which was extremely buggy on FireMonkey. Steema acknowledged some of the bugs, but never fixed them or provided workarounds. It was around fall, and Apple released a new iOS version. Debugging capabilities in RAD Studio broke and I was more or less flying blind. I think something like this still happens today. Overall performance was completely random, sometimes it was stuttering extremely badly or just terminated. I suspected memory leaks in FireMonkey or TeeChart Pro, but had no way of tracking that down. I felt that if I had stayed with "native" development options (like Apple XCode), I might have had better chances of getting behind such problems. At that time, it was impossible to re-use much existing Delphi because because of the fundamentally different memory management model. I haven't followed it, but I think this should no longer be a problem: Directions for ARC Memory Management in Delphi All in all, it was considered a failure and we scratched it completely.

Windows Event viewer might be helpful to determine why exactly it crashed. For me (mostly working with 10.0 Seattle) it is rather "normal" for it to silently collapse because of memory exhaustion after working with it for an hour or two. bds.exe will then just silently terminate.

It sounds rather straightforward. From your description, I don't even see the need for using TThread. Instead, I would Declare your each of your work items as a Task (from the System.Threading unit) Put all those tasks in an dictionary, so you have a relationship between your tree view item and the task Start the tasks In a timer, check which tasks are finished, so you can tick your checkmark in the treeview See Parallel Programming Library Tutorials - RAD Studio for more information and examples.

Can somebody shed some light on that? I don't really know much about heap fragmentation, but it is one of my worst nightmares.

I spin up a new VM and start fresh.

Why did you mark the parameter as var in the first place?

Didn't even know that was possible. Thanks.

Don't forget to set the Name property of your frame to something unique. Otherwise, it will throw a runtime exception when you have several components with identical name in the same container.

Jesu mentioned using Data.DB.TParams.ParamByName which returns a Data.DB.TParam object. TParam has a property Value which is a Variant. As much as I loathe these things, the approach by @Virgo seems to be the most fitting.

I am using Sqlite exclusively, because I don't know anything else.

You may be able to use tools like "Dependency Walker" to find out which dependency includes avrt.dll. I wouldn't be surprised, however, if that's straight from the VCL. The flags in (2) seem to be PE header flags in your executable. I wouldn't even be surprised if half of them are some "Visual Studio only" flags by Microsofts Linking executables. Can't the auditor be a little more helpful and provide some context?