FPiette

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.

You are at the right place. A package can be either designtime or runtime or both. You select what you need. To get "install" in to project manager popup menu, a package must be "Designtime" or "Designtime and runtime".

Not sure I correctly understand what need and what you've done. I understood that you copied Delphi source code in another unit and then modified that unit to fit you needs. Then why not modify it further to make visible what you need ? btw: Modifying a Delphi unit although technically correct, will make your application difficult to maintain on the long term as Delphi source code will change: you'll have to apply your changes, if possible, to the new source and this may be difficult or even impossible. To avoid this problem, you probably have to change your design.

You should display the ErrCode argument in OnSessionConnected event handler. I'm sure it is something like 10061. If the connection is successful, then the ErrCode is zero. Same for OnSessionClosed. OnSessionClosed is immediately called when the connection fails. So what you see is normal behavior.

Maybe the server you connect to wait for some request. If nothing comes within a given time, then the server close the connection. In your code, you should add an OnDataAvailable handler to read incoming data and display it. Why not first try one of the client demos provided with ICS distribution?

You package must be flagged as "Design time page". See the package project options.

Data to be sent in a TWSocket (Any derived class) is stored in a dynamic buffer until it can be sent. Once a chunk of data has been sent, the memory is reused. This is used to implement the asynchronous nature of TSWocket. No matter how much data you send by calling one of the send() methods, data is buffered and send() returns immediately while your data is sent in the background at the speed the network accept it. So if you send 100MB of data, for example in a loop reading a 100MB file, it will then be saved entirely in memory. If you don't like this behaviour for any reason, sent on data chunk at once and use OnDataSent event to read your next data chunk and send it. On receive, your application get an OnDataAvaiable event. No data is buffered by the component. You MUST read all data available from the OnDataAvailable event handler.

You mean just remove or replace by somathing else?

The answer given by @Lars Fosdalis correct, but there is an alternative method: instead of querying the status with a timer, you can simply install a handler for WM_SIZE message and inspect the SizeType argument. When the windows is minimized (become iconic), SizeType value is SIZEICONIC (1). See Microsoft documentation for WM_SIZE TForm1 = class(TForm) private procedure WMSize(var Msg: TWMSize); message WM_SIZE; end; procedure TForm1.WMSize(var Msg: TWMSize); begin if Msg.SizeType = SIZEICONIC then begin // Do something end; end;

That's a way to do. I always prefer using the events for connection and disconnection.