Leaderboard

Today one cannot write two simple methods and be happy. There must be classes, interfaces, factories, patterns etc - that's the serious approach . Have you seen the FizzBuzz Enterprise Edition ?

I have also been using a variant of code from Jeroen W. Pluimers website. I have incorporated it into the hcOPF project and added support for FMX. The code credit contains the original blog post. hcTemporaryCursor.pas

Yep. Screwed it up. How do you get the individual quote sections into the reply please?

I usually use a simple class with a counter and two methods, like BeginWait and EndWait. The first one increments the counter and sets the cursor to crHourglass if the counter was 0, the second one decrements the counter if it is positive and reverts the cursor back to crDefault when the counter is 0. Of course, with the obligatory try..finally to make sure that each BeginWait has a matching EndWait and with critical sections if multithreaded.

Why would that be odd? That's pretty much a canonical use of try finally.

These days, I avoid changing the cursor at all, but provide feedback in other ways. If it's a long running process, it'll be performed in a background thread. If you really must change the cursor, be sure to save its current value, and wrap it all in a try..finally, e.g. SaveTheCurrentCursorAndChangeToHourGlass; try DoSomeLongProcess; finally RestoreCursorToWhatItWas; end;

As François says, you should be using TWSocketServer which handles aspects of accepting and closing connections, you just plug in your existing onDataAvailable code. Also makes it easier to move to SSL in the future. If you are using the HTTP protocol, there is a new component TSimpleWebSrv in OverbyteIcsSslHttpRest,pas which uses TWSocketServer and adds a simple HTTP protocol, just a few lines of code, ICS uses it for lightweight HTTP servers for OAuth2 and Lets Encrypt. Angus

Look at TWSocketServer if you want something basic able to listen for client and instanciate new TWSocket for each client. It doesn't do anything special related to HTTP protocol which is handled by THttpSrv component. As you can see there is a full hierarchy of classes each one being more intelligent. TWSocket is below everything, TWSocketServer add support for server features above TWSocket. THttpServer add HTTP protocol support (server side) to TWSocketServer. THttpAppSrv add REST application layer to THttpServer. In this hierarchy, there are some more intermediate classes for "custom", "Line mode", "proxy", "SSL/TLS" and more.

Perhaps they could buy Greenland as well

For an IDE package to work in Delphi 10.3, 10.3.1 and 10.3.2 it has to be compiled with 10.3 or 10.3.1 in the first place. The compatibility patch is needed to make such an application work with 10.3.2 (actually the patch is meant for 10.3.2 installations only). There is no way to make a package compiled with 10.3.2 work with 10.3 and 10.3.1. This case is a bad combination of first breaking compatibility by accident and then refuse to fix it because that would break some other compatibility.