FPiette

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

Inheritance is maybe the most fundamental concept making a record different from an object. Record, managed or not, are definitely not classes. I never found any memory management issues with classes.

@pyscripter I'm surprised, that you call CreateDCRenderTarget, you get a ID2D1DCRenderTarget while you need a ID2D1DeviceContext to call Direct2D 1.1 or later specific functions. Maybe I missed something? Looking at https://docs.microsoft.com/en-us/archive/msdn-magazine/2013/may/windows-with-c-introducing-direct2d-1-1 I saw this sentence: So I'm using CreateDeviceContext instead CreateHwndRenderTarget. And all other steps required as explained in the above mentioned article. When using a single Direct2D window, the speed difference is not really visible. But as you saw in my application, I can have 50 or even 100 small Direct2D windows. And with as much windows, the speed difference is highly visible. The screen shot in the first message of this thread has 49 small windows and takes 10 seconds to build with Direct2D 1.1 and less than one second with Direct2D 1.0. Then if I open a single image to see it in big, there is no noticeable speed difference (Zoom, pan, flip and rotate) because the time scale is to short. Everything is done in a fraction of a second. I could replace the small windows by a single one showing a single bitmap constructed from all thumbnails. But this would require a lot of works and is much much less convenient. Not to much visible on the screen dump, but the is a checkbox and also frames and various display effect which are really easy to do with the small windows and would be much more work with a single window.

There are now "managed records" which are not classes. See the documentation: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Custom_Managed_Records

In the context of this subject, an interposer class is a bad solution. An inherited class is the correct way. In general, I avoid as much as possible interposer class. I think this make code more obscure. But not everyone share my opinion and that's OK.