Leaderboard

Thank you so much, it took a lot of extra work, but i finally managed to get the nmea messages.

I have found an answer Next, before launching the DevServer, Go to Tools | Getit Package Manager and install the EdgeView2 SDK. Then copy in the WebView2Loader.DLL into the same directory from the redist directory. The Devserver needs to be in a writeable directory because the WebView2Loader DLL needs to create a subdirectory. I actually created a separate RADServerFCM directory with EMSDevServer and its dependent packages just to create the RefreshToken entry. If you are on a Windows 11 machine this should then work. If it is on Windows 10, you will also need to install the WebView2 SDK. The WebView2 will allow Google's login screen to display. To send messages, please ensure that you are using the binaries from Delphi 12.3. There was a bug in 12.2 that required the use of libcurl.dll and even then only the 32 bit version of RAD Server could be used. The version should come back as 4.9.

Hi all, thanks for all suggestions and advice. Problem was solved just maintaining exactly the same code written years ago with old ICS version but with only one change. This change, as suggested by Angus and Remy, was to replace the "TWSocketServer" socket declaration with simply "TWSocket". UDP Server started working again. Next time I'll read the whole documentation before making updates. 😄

Robust? It seems to me that the current implementation is pretty robust. Just because it doesn't do or behave as you'd like doesn't make it wrong; It's an age-old utility class that has to conform to a certain contract in order to not break a gazzilion applications. Regardless, it should be pretty easy to implement a helper that hacks access to the TStringList.FList array and then simply manipulate that array directly. Or you could just copy the TStringList source and modify it to your liking.

there's also the old: IndexText or IndexStr method System.StrUtils.IndexText - RAD Studio API Documentation

It's strange that Delphi still doesn't have a proper multicursor. Like in SublimeText. Ctrl+Shift+J and Cltr+R are not always convenient.

May I suggest "fluent interfaces" as an alternative to nested calls. Instead of using a record like a dumb data store that is only manipulated from the outside, you can put the methods that fiddle with the record's contents directly into the record itself and thus keep the code and the data closely together. Also, this enables one to use a so-called "fluent interface". Example: This is an example of a record that contains just one integer member, "data". In real life, you can make the record as complex as you want. type pMyrecord=^tMyRecord; tMyRecord=Record data:integer; Function Reset:pMyrecord; Function Add (x:integer):pMyrecord; Function Multiply (x:integer):pMyrecord; Function Divide (x:integer):pMyrecord; End; As you can see, all the methods in this record return a pointer, which simply points to the record itself. That is the "secret sauce" one needs to implement fluent interfaces. function tMyRecord.Add(x: integer): pMyrecord; begin data:=data+x; result:=@self; end; function tMyRecord.Divide(x: integer): pMyrecord; begin data:=data div x; result:=@self; end; function tMyRecord.Multiply(x: integer): pMyrecord; begin data:=data*x; result:=@self; end; function tMyRecord.Reset: pMyrecord; begin data:=0; result:=@self; end; Now the cool thing: All these methods can be concatenated and will be processed left-to-right. This produces very legible and compact code: procedure Test; var x:tmyrecord; begin x.reset.add(12).multiply(4).divide(2); end; (edit) Note that I didn't do a single heap allocation here, never manually passed the record as a parameter and never did a nested call. The data lives on the stack. If the record contains managed objects such as strings, these are disposed of automatically.

My preference would be similar, but I'd start with private const and end with private fields.

In some occasions the inaccuracy of Delphi's TTimer cased serious headaches so I did some digging and found an old post on how to turn a thread into a much more accurate timer. While I analyzed the code to find out how it works I made some comments and also took the liberty to change it here and there... and wrapped the whole thing in a TComponent which easily can be installed in the IDE and dropped on almost anything. The TThreadedTimer's OnTimer event runs in the VCL thread so any UI element can be manipulated from there. It is also a drop-in replacement for TTimer, meaning you change your DFM and PAS and it should work exactly the same way. My version delays enabling the thread so it won't spin freely until it has an event handler, properly resets the timing sequence if the Timer is set to Disabled and then Enabled again and also - in theory - the OnTimer event will no longer fire during destruction. Being a Windows-only guy it relies on WinApi, but I guess it can be made cross-platform by using Delphi's own TEvent class... as it yields zero benefits I didn't care to look into it. As the original idea wasn't mine the right thing to do is to release this version under the do-whatever-you-want license. Feel free to use, point out possible issues or modify it to fit your needs. God bless open source 🙂 uThreadedTimer.7z

Yes, @Bill Meyer is right: do not put the nested functions part of the main class. It would break SOLID principles for sure - at least the single responsibility. Always favor composition in OOP. About refactoring and breaking huge functions, you could take a look at those slides: Following these proposals, for code refactoring, I would move the code into dedicated records with methods (or classes).