FPiette

You should not destroy the component from an event handler of that component (general rule, not specific of ICS) or you'll experience access violation or other strange behavior. From an event handler, you can defer the destroy using a PostMessage of a custom message. That is what TForm.Release does by the way.

Do you have gtClasse3.pas or gtClasse3.dcu somewhere in Delphi search path or project search path, or directly added in your project? Any typo error?

Yes, I have no idea who you are!

No, only TCP. UDP is a datagram oriented protocol. But you are able to discover which protocol is used in your processor stuff. What I say is that you have to move the part of the code out of the processor code and move it to an intermediate layer between the low level receiver and high level the processor. Layers is the key success in protocol handling. RawByteString is low performance. It is all about memory alloc/free, data copy and memory fragmentation. Low performance but easier to design and develop. Linked list (Or queue if you want to encapsulate the linked list in another name) is the way to go for performance as I explained. And yes, I agree that this is more complex to design and develop but this is the price to pay for performance. I bet you will never do that change. You'll buy a higher performance computer.

Not tricky but less trivial. As someone else said in this conversation, performance often means more complex solution. You put your priority where you want! Maybe you don't know, but I'm the author of ICS (Internet Component Suite) and what you describe is exactly what happens with a TCP stream which is what a TCP socket gives. So I have large experience in that kind of data receiving handling. There are 3 ways to delimit data: 1) There are delimiters such STX/END around a data block or a CRLF (or any other end-of-block marker) at the end of data block. 2) Each block begins with a data length. 3) Communication is closed or broken You should move the determination of the data block complete/incomplete in the receiving process or thread, not in the processing thread. This means that the same buffer (Pointer and length or pointer to star, offset and length) is given to the low level receiver until a complete data block is received. Only then this data block is put at the end of the incoming data linked list (or Queue if you prefer this term) for processing.

So this is perfect for a linked list! The linked list will grow as the source data thread add more buffer at the end. Buffer extracted from released buffers after processing or new buffer if no free available. Processors, will take a buffer from the start of the linked list for processing and move the buffer to the released linked list. Then you have to have a linked list per source data. When a processor retrieve the first buffer from the linked list and determine it is not complete, then it is flagged and it stays in the linked list. When the next data chunk arrive, and the first buffer in the list is flagged as incomplete, then it is flagged as fragment so that the processors knows that if must also retrieve the next item in the list (or a few ones) to get complete data. btw: Linked list are frequently used to implement queues (FIFO, LIFO). I never seriously looked at how Delphi RTL implement TQueue<T> but I think it is an array which is less efficient.

You'll get performance if you avoid copying data. If your receiver component accept a buffer (You said TBytes which is a TArray<Byte>), you can keep it into that buffer, add that buffer in a linked list of pointers to those TBytes buffer and pass another buffer for the next receive. Each "processor" will then receive the data it know how to handle right and produce some result maybe in the same buffer or in a new one. One a buffer is not needed, it is freed or better put on a second linked list with available buffers and reuse that buffer later. You'll avoid memory allocation/deallocation which produce memory fragmentation which is also very bad if the application has to run continuously. Resizing and array (Remember TBytes is an array) is an inefficient operation. It involve copying data because the array can't always be expanded in place and obviously it involves memory alloc/free because you use a dynamic array (TBytes). I don't know what your receiver looks like nor if the data size is known up front. But if possible, it is better to preallocate a buffer large enough for - let's say - 90% of the occurrences and reuse that buffer again and again (Because as I said above you have a linked list of free buffers).

Linked list is among the fastest. Much faster than arrays or strings. But since you didn't told us how data is coming and which processing you need to do, all answers (Mine and from others) are just guess and probably not really helpful. You'll get performance if you minimize the number of data copy and memory allocation. Be aware of hidden data copy and allocation when you resize a dynamic array or a string and all variation.

You forgot a data structure specifically designed to handle the processing of your data. For example linked list of some basic data type. Since we don't say anything about the details of your processing, I can't be more specific.

Yes, this is what is required. No need to build one for Delphi since it already exists.

Have a look at this answer on StackOverflow. It is about a TEdit, but IMO the same concept applies to a TComboBox.

Use a TTimer to change the color of the button periodically. If you need a lot of them, you can derive your own TFlashingButton class/component to have an easy to use flashing button on the tool palette.

Maybe this: https://www.virtual-serial-port.org

I use dxGetText (https://sourceforge.net/projects/dxgettext/) in all my application which must support several languages. To do the translation it self, I used PoEdit (https://poedit.net/). I have never been confronted to some parts being translated in one language and others translated in a different languages but I think it is possible to do it since translation process pass by functions you have control on it.

I am using that solution with great success. 1) The main service launch a child process which does the work. 2) The main service is notified by Windows when his child exit (You can have a thread waiting for process termination). 3) The main service check child process health by sending a request using IPC. In my case the child service is accessed by clients so the main service use the same code to connect to the child process. If the connection fails, then the main service kill the child process. 4) When the child service gracefully terminate it set a flag so that the main service do not restart it but also close. The flag is actually a file created by the main service and deleted by the child process when terminating properly. If the main service detect the file is still there when the child process terminate, then the child process crashed.

For that kind of bug, a step by step execution using the debugger make it obvious!

Even when you know the length of data supposed to be sent by the sender, it is important to read data as much as it comes in for the reason I explained in my previous messages. More data can come in because the sender queue requests without waiting for prior answer, or maybe the sender is simply trying to hang your application (DOS attack).

I use madExcept for that purpose. Be sure to select "crash instantly on buffer overflow" (or underflow).

One more warning: When using TCP, there is no packet at all, just a stream of bytes. What the receiver sees is totally independent of how the sender send data. The sender may call a single send and the receiver have two OnDataAvailable events and the sender may call several send but the receiver receive only one single OnDataAvailable event for all data. Writing a program using TCP assuming there is a correlation between sender's send() and receiver OnDataAvailable will sooner or later explode on your face! (Frecnh expression).

Sure, but if data is not read, the program get stuck in that loop forever. That is why it is important to read all data and throw away what is not possible to keep, raising an exception or showing an error because throwing away data silently will make the program have unexpected results - for the less.

var Request: string; begin Request := '{"appKey":"' + AppKey + '","secretKey":"' + SecretKey + '"}'; Request is a local variable and the way you initialize it is perfectly correct. Each time Login() is called, you get a new variable (on the stack) which is initialized. If this doesn't work, then there is something elsewhere corrupting memory. That will be difficult to find. Especially for us which have no view on your code.

It is sometimes very useful when you have to port code from another language which makes use of that feature. It is not always easy to replace several variables in a single function having same name but totally independent.

One more important thing: In the OnDataAvailable event, you should read ALL data arriving. So you should make a loop calling Receive until it return < 0. If the buffer used for receive is to small, read anyway in a secondary small buffer and throw data away, then signal the error to the user "buffer to small".

Do not rely on RcvdCount to know if data is ready to be read. In some case, winsock returns 0 even if more data is available. Just call Receive and use the return value. Call Receive again until Receive returns < 0. This is not an ICS issue but a known Winsock behaviour, that's why you experience the issue with both ICS and your old socket component.

Try to write a very simple program to reproduce the error. For example a single form with two comboboxes and a button. Implement the logic you exposed in your question and in the button OnClick, just call ShowMessage. If it doesn't work, publish the code here. If it works, then double check you application to find whicg error you made.