FPiette

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.

I suggest to first extract all strings used as key from the grid along with their index and move them in a single buffer (Avoid numerous memory allocation), keeping the pointers into an array (of pointers). Then use a fast algorithm to sort the array of pointers by dereferencing the pointers to access the strings for comparison. Moving only the pointers is the key to fast operation. Once the array is sorted, use the index part to move the grid rows. This will be efficient for a large grid because strings are moved only once to create the array of pointers

Could you elaborate on this subject? You select the mutex name. Choose something unique for your application. I my memory serve me well, there is a single instance component in either JCL or JVCL.

This is governed by a registry key: https://support.microsoft.com/en-us/help/182569/internet-explorer-security-zones-registry-entries-for-advanced-users It is likely that your program need elevated privileges to change that.

Using your code with Delphi 10.4.1 and your test file, I cannot reproduce the issue! Maybe something else in your application? Try with a simple project with only one button and your code in the OnClick event.

You should post the code you use to validate the XML document. Build a minimal program which reproduce the error you get.

That's why I said in the message to prevent re-entry issue. as with many things, calling ProcessMessages is perfectly correct if you understand what happens when you do so.

Sure I did since the poster (You !) want to process all inputs (QS_ALLINPUT). If you don't consume messages then MsgWaitForMulpitleObjects will immediately return WAIT_OBJECT_0 + 1. And if you don't process the messages, the main thread will be freeze and you asked to not freeze. Maybe I misunderstood your question. If this is the case, a better description is welcome.

It is possible to overcome some of the issues by implementing a notification mechanism. Much like it is in any TForm for components it owns.

Does it happens to you only or also other computers on the company LAN?

For logging, I find handy to use OutputDebugString. The messages are shown in the debugger log view.

procedure TForm9.Button1Click(Sender: TObject); var Thrd : TThread; Ret : Cardinal; HandleArray : array [0..0] of THandle; begin Thrd := TThread.CreateAnonymousThread( procedure begin Sleep(5000); Memo1.Lines.Add('End of Thread'); // Not reliable! end ); Thrd.Start; HandleArray[0] := Thrd.Handle; // The thread above is waiting for 10 seconds within itself. // We will wait for the above thread to finish before the main thread freezes while TRUE do begin Ret := MsgWaitForMultipleObjects(1, HandleArray[0], FALSE, INFINITE, QS_ALLINPUT); if Ret = WAIT_OBJECT_0 then begin Memo1.Lines.Add('WAIT_OBJECT_0'); break; end; if Ret >= (WAIT_OBJECT_0 + 1) then begin Memo1.Lines.Add('WAIT_OBJECT_0+1'); Application.ProcessMessages; continue; end; if Ret = WAIT_TIMEOUT then begin Memo1.Lines.Add('WAIT_TIMEOUT'); break; end; Memo1.Lines.Add('Else') end; Memo1.Lines.Add('Thread finish'); end; Pay attention to change the access to Memo1 from the thread. Pay attention to re-entry issue. You should probably prevent it.

This doesn't answer your question, but using Memo1 from the thread is not allowed. VCL is not thread safe.

Everything still normal as seen from here. It is probably your system which has been compromised. You should urgently conduce a malware scan with up-to-date anti-malware software. If you don't find anything, try scanning by booting you system out of an independent bootable device (Rescue disk or something like that).

https://docs.microsoft.com/en-us/windows/win32/coreaudio/volume-controls

Thanks. This is Direct2D 1.0 code that already use. I see you get a DeviceContext when you need it to render the SVG document. So you are not following at all what all the articles about Direct2D 1.1 explain. I wonder where the drawback is... Future will tell...

My application has thousands lines of code. I need a tool which does this automatically.

But then I have to manage a huge number of bitmaps, frames, checkboxes in that alone window. Now i have a component, like a TPicture which does everything and I use NxM of such components, only changing the coordinates according to the size the use gives to the application window. This approach is very efficient with Direct2D 1.0 and 10 times slower with Direct2D 1.1. How do you get the RenderTarget? Do you do the same as with Direct2D 1.0, that is just call CreateHwndRenderTarget or CreateDCRenderTarget? No Direct3D device, DXGIBackBuffer, SwapChain and other things mentioned in https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/may/windows-with-c-introducing-direct2d-1-1 and https://katyscode.wordpress.com/2013/01/23/migrating-existing-direct2d-applications-to-use-direct2d-1-1-functionality-in-windows-7/ ? Thanks