Fr0sT.Brutal

Actually there's some kind of syntax sugar for Variants - they could accept any "member" that is translated to g(s)etter with string name of that member. Not really helpful though but could shorten some code a bit

I still recommend HTTP. You'll have to invent your own protocol anyway so why not use already implemented one. Low-level Data events and buffer plays will be hidden from you by higher level events and classes.

Why not use HTTP here? I started some kind of this stuff and got it working but postponed for production. ICS HTTP server procedure TControlServer.ProcessRequest(Client: THttpConnectionEx; SendType: THttpSendType; var Flags: THttpGetFlag); begin ... if AppStatus.FormImg = nil then begin Client.AnswerHeader(Flags, HTTP_Status_204, HTTP_Type_TxtHtml, ''); Exit; end; Client.DocStream := TMemoryStream.Create; Client.DocStream.CopyFrom(AppStatus.FormImg, 0); Client.DocStream.Position := 0; Client.AnswerStream(Flags, HTTP_Status_200, 'image/bmp', Client.DoContentEncoding); end; ... enf; Bmp because screenshot is in bmp, just to not deal with encoding. With this code I got an image of main form available even in any browser

Don't these libs implement server side while OP needs client? General hint: if you have some REST soft working and some not, get the dumps of their requests and compare. That will be much more useful than any guessing. curl can dump all traffic with some options but I'm not sure about Delphi client... still, you can use Wireshark (traffic sniffer) for this or some special proxy.

Weird. It is based on ICS which supports TLS

Amazingly exhaustive answer! Looks like you also highly value your time on writing a meaningful post 😄

+ for Filezilla - and honestly there's no other simple free solutions that I'm aware of (besides your own app built on Indy or ICS class). However, I only prefer 0.9.x versions as they changed much in 1.x and I couldn't get it working - some dumb cert issue

Bad practice that Delphi RTL started itself. If usual clause is not applicable for some reason, why not write "raise CreateInternalError(...)"? Mystery for me

Damn! You're right! Mixed these Germans (LOL) singing about Russians with those 😄

Not at all. I'm fine with objects where applicable. Some of my projects have singletone Settings, some use more complicated techs for communication. However I won't bother with object overhead where there are only a few global options exist. What I consider bloat is using datamodule for storage. Just a simple class located in common shared unit will serve equally and without excess entities involved. Anyway, I didn't see YOUR suggestion besides placing stuff into datamodule which is just "the same eggs but from a sideview" as global singletone. Okay, my habits are bad and old and non-OOP, what will be your solution?

Oh those (Jewish) Russians... © Dschinghis Khan

I guess the reason is the way you call the function. Likely the code before function call zeroed the corresponding stack area on x32 but didn't on x64

and so many actions just to hold non-TComponent stuff? Honestly this is a bloat for no reason. 0 pro's and several con's => no-go for me

Live templates work well for me So all users must remember which properties are retrieved and which are calc'ed? And code insight becomes almost useless?

I did not but see no problem here.

It's also interesting in what timezone the working hours are.

Quite acceptable solution IMHO. I've never had a need for different access levels to properties though. In rare cases of protected setters that must be called from outside I just execute these setters.

I recently stumbled upon QT API where there's no properties and it looks REALLY awful. Instead of Class.FooProp they have Class.getFooProp and Class.setFooProp. API size is doubled with no real necessity. So properties are awesome. Drawback is that they sometimes do too good job hiding implementation details so a user utilizes them with huge perf impact (Memo.Text := Memo.Text + s - this looks too simple but contains pretty heavy code underneath). Moreover, mechanism of published properties allows automatic (de)serialization - DFM, JSON, XML to and from object could only be done via properties

Have you cloned whole repo? Mine starts from 2009 with 4.8 mentioned

I wasn't going to go too deep in describing all these design patterns, I'll leave the prize for most huge posts to you 😉 All I wanted to say by "and so on" is said in the 1st line of my post which seem to hide from your attention as well, eh? Sure. What does matter is how to perform further refactoring. With standalone global var you have to search for its usage filtering out possible name collisions with local vars. My way leaves all this work to compiler - force "namespace" and then easy search by an unique name of that "namespace". A data module is not simply a class but more like a form. It requires DFM. Why DFM when there are no components inside? That's excess. You don't have full and flexible control over when a DM is created. You have to track form creation order. For me that's kind of riding down the hill on an office wheeled chair. In theory, you can. In practice, it's senseless.

Made in Taiwan 😄

Github repo Most likely - double free when VTV's OnFreeNode disposes linked object and it also gets freed somewhere else

You likely didn't read the next line I wrote. Datamodule usage is senseless here for me. It's a container for components useful for design-time customizing but nothing else.

Official Lamborghini screwdriver and Official Lamborghini wrench? XD