DelphiUdIT

Or you can create a Thread, where you can run every code you need without UI interactions. https://docwiki.embarcadero.com/Libraries/Athens/en/System.Classes.TThread

Yes, they are "alive". And they are working on, but FMX Linux means "FireMonkey X Linux" ... so ...

The getit server is down (or is not working) since Saturday.

Sorry, I understood wrong the question. My fault. It's better thta I wait some more details before speaking ...

You can look at examples posted, they use strings in ShowMessage ....

In the example thay gave, the equivalent expression is a typical IF, so we can deduce that the new expression also behaves in this way: the part not affected by the condition will not be evaluated. Of course, only they or the release can confirm this.

Make a prevision on what they will produce is only a fantasy. I think, 'cause the next is a major release, that will only be the beginning of a series of new features that will be proposed to us. But, ...... if some MVP were authorized to release some other substantial news, even if not seasoned with technical details ....

I don't think so, if you read the full topic you'll see that there is no patch on FPC and they are working on (I don't know how much). May be after the public release of Rad Studio 13 whit all notes they will speed up the production of a patch.

@Eugene Kryukov My only concern was related to the scrupulousness of maintaining the compatibility with the past that ICS still maintains. I don't need proof or anything else. @Anders Melander I was referring to old versions, not ancient versions (I know you meant to point out that the nil test has existed since the first versions of Delphi)

Uhmm, I don't remember how FREE procedure is operational in the old versions of Delphi. If the FREE TObject procedure doesn't test the NIL before destroy it ... So for new Delphi version is OK, but for older you should see.

I don't know. I worked always like I wrote with 1 thread for ModBus connection. But I had what I show changed at that time, with no comment (my fault ) and there were no pratical reasons to had done this. May be like you said something about multithreading with access to IoHandler, and that only change something obscure ... To do some datas, this week (7 days) a line that works near 8 hours / day have done more than 15 milions of reading (MODBUS) from PLC with only 5 failures and more than 1 milions of writing with no failure (that machine were in test with monitoring all working parameters, also double check about write ModBus register and read back the values).

About the Connected "property. In my code I used to do this: //PLcBot is TIdModBusClient //THIS IS PRIVATE procedure used ONLY INSIDE A THREAD procedure TPlcComm.fprocBotIP(value: string); begin if PlcBot.Connected then <--- connetcted tested like normaly should be PlcBot.Disconnect; PlcBot.Host := Value; try PlcBot.Connect; except on e:exception do ; end; end; //This is the test connection used OUTSIDE the THREAD, via a READ ONLY property function TPlcComm.fGetPlcConnection: boolean; begin if assigned(PlcBot.IOHandler) then <---- Test CONNECTED used in another way !!! result := PlcBot.IOHandler.Connected <---- else result := false; end; The test about connection state is used in different way if used outside the thread or inside the thread, may be at that time (many and many years ago) there was something wrong about that. It has been working for at least 8 years (this part was last updated almost 8 years ago).

I use Indy Bundle and the same Modbus component to read a PLC (Encoder conuter) every 10 / 15 ms. and write on them every 150 ms. (EDIT... I do this since 8 years and there are dozen of machines that work in this way 24h/24h). I never had such problem. TAKE CARE that you cannot use Indy (and ModBus too of course) from differnt Threads (you spoke about use it in Main Thread too). Try to modify the logic and work from single Thread (where you can create and use ModBus) ... untill you are sure the Indy operation don't interfer between threads.

@@AT I still think you don't understand the function of Interlocked and how it works. Even in your example, you use loops to verify that the function "succeeds." This is legal if the variables are modified by other threads and you enter that "loop" indefinitely until the variables assume an identical value to exit. But since you also mention collisions, I think you actually believe that Interlocks are executed or not based on collisions. That's not the case. It's not a mutex or a semaphore, and it's not a critical section. Interlocked simply protects a memory area from "concurrent" modifications. And note that in reality, most direct memory operations are already intrinsically protected. For example, INTEL guarantees the atomicity of some operations such as direct reading or writing, which involves a register and "byte," word, dword, etc. memory if the memory is aligned. XCHG instructions are also atomic (unlike complex instructions like CMPXCHG) as long as they operate on aligned memory. LOCK can be used on multiple memory-operating instructions to ensure LOCK even in unintended cases (e.g., unaligned memory). Ref: "Intel® 64 and IA-32 Architectures Optimization Reference Manual: Volume 1, April 2024"; Ref: "Intel® 64 and IA-32 Architectures Software Developer’s Manual, March 2025" Caution: Interlocked functions generate a significant delay in instruction execution (i.e., the instruction executes in more clock cycles than normal).

The code with ".CompareExchange" in you example cannot exist in that way. The "unsuccesfull" exchange is not about a collision but a comparison: look at https://docwiki.embarcadero.com/Libraries/Athens/en/System.SyncObjs.TInterlocked.CompareExchange I think you confuse the Interlock with something else. Interlock operations ensure that these are performed SINGLELY in a multithreaded environment (there's no point in using them otherwise). But these operations are ALL ALWAYS performed. The hardware determines how to do it, but it does them all one at a time. The sequence is not and cannot be known in a multithreaded environment. For example, these operations can be used to increment a global counter from multiple threads. If the "target," i.e., the memory to be modified, is the same (since it's the same variable), interlock operations prevent multiple threads from colliding and generating a race condition.