Der schöne Günther

That's a lot of text and code on your readme page. I must admit I did not read all of it, especially the code. I still have a some questions: Since Delphi cannot put constraints like "can be ordered" or "has an equality operator" on generics, your function seems to work on all types of T. What is the runtime behaviour? For example, what happens when comparing two arbitrary records? Why did you not use DUnit or DUnitX for unit tests and instead rolled your own console application? PS: You committed some unnecessary files (like .exe, .dcu, ...) to your repository. Only the source is necessary. For creating .gitignore files, there are tools like https://gitignore.io/

It's not my area of expertise, but I'd be sure you won't solve this without a proper browser plugin/extension which may then receive its data from outside. I doubt a simple binary executable from "outside" can reliably do this without breaking with the next browser update.

This also happens with me all the time. There is no method to this madness. When developing with Delphi, I usually spend 10 - 15 % of my time reverting unwanted changes or being extra careful to not commit them. If you are not using any kind of version control, this is clear sign that you should start getting familiar with it now

Oh sorry, was this a C++ question? In that case, let's add p_int = &2[arr]; std::cout << "p_int points to " << *p_int << std::endl; // 102 to the list, just for fun.

Make sure the type of your pointer is correct when doing stunts like pointer arithmetic. For example, PInteger when dealing with Integer. Short example: program Project1; var int: Integer; ints: TArray<Integer>; p_int: PInteger; begin int := 42; p_int := Addr(int); WriteLn('p_int points to ', p_int^); // 42 ints := [100, 101, 102]; p_int := Addr(ints[1]); WriteLn('p_int points to ', p_int^); // 101 Inc(p_int); WriteLn('p_int points to ', p_int^); // 102 Inc(p_int); WriteLn('p_int points to ', p_int^); // (some random number) end.

I don't know what this is exactly, but you will need the WebView2 runtime from here: https://developer.microsoft.com/de-de/microsoft-edge/webview2/

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.