Leaderboard

1. I have reduced the test project (in source.zip on page 1) further and have a very small observation: With only three components (RadioGroup, TreeView, ListView) the memory leak disapears. But the memory leak (after switching style at runtime) is back when TreeView and ListView are children of (the same) Panel. I needed to bring back the panel! In other words: The observation is that the parent Panel plays a role. Why is it that we need a Panel (or maybe other common parent component) to see the problem? 2. Confirmed that the TListView.WndProc override 'works' in Tokyo.

The issue results from the TListView being recreated as a response to the CM_STYLECHANGED message (see CustomListView.WndProc). If you add the following at the top of UMainForm.pas TListView = class(Vcl.ComCtrls.TListView) protected procedure WndProc(var Message: TMessage); override; end; with the following implementation procedure TListView.WndProc(var Message: TMessage); begin if (Message.Msg = CM_STYLECHANGED) then begin if ViewStyle = vsReport then UpdateColumns; end else inherited; end; the error does not happen. There does not appear to be much point in recreating the ListView, since its handle would have already been recreated, when the form it resides gets recreated. Still it remains a mystery why the recreation of the ListView affects the TreeView! The memory leak is also prevented by calling RecreateWnd after changing the style. In the process of debugging, I discovered another Vcl bug: [RSP-33221] CM_STYLEDCHANGE is broadcast twice - Embarcadero Technologies

You need to remove the build event from the project options. This was stated earlier in this thread.

You should understand what all these redirections are: if this is endless loop of redirections, then many options: fix the server logic; use different URL; provide additional headers (eg authentication); etc if this is long chain of redirections, then set MaxRedirects to a higher value.

No surprise there - linear search is O(n), binary search is O(log n) and hash table is O(1), what you see with the differences for certain number of records are the different constant factors - building a hash has a certain cost which is why TDict is slower up to a certain point - this depends on the hash algorithm being used - indirections being caused by extra function calls like IEqualityComparer.GetHashCode and the memory layout of the hash table. You can even see that it's not strictly O(1) as it gets a little slower the more records you have which I would guess is due to memory layout within the hashtable where at a certain point memory access time kicks in because the data does not fit in the fast cache anymore (access pattern of the benchmarking code matters there as well). Without specifying the exact use cases it's hard to give any suggestions - is the data one time fill and then only lookup, is data being changed after - adding/removing records, is data within the records changing. Whats the typical lookup pattern - is data being looked up randomly or in certain patterns (such as ID or Name sequences in certain order). If you aim for maximum performance a custom data structure and algorithm will always win over some standard algorithm by a few percent - the question is if you want to do all that work including risking bugs for that negligible few percent or use some standard data structures and algorithms that are proven to work and easy to be applicable.

To send text you could use this function. If the previous change fixed the issue I suppose this will also fix it without to change anything else. You could also store binary data in AnsiString but I would not do this. It's better to use TBytes for this. procedure TThermalPrinter.SendString(AValue: AnsiString); var SND: TBytes; begin SetLength(SND, Length(AValue)); CopyMemory(@SND[0], @AValue[1], Length(AValue)); LSockect.SendData(SND); // send data to the printer end; And better this in TThermalPrinter.DoPrintBitmap() vTempStr : AnsiString;

I removed as much as possible from your demo. It's now independent from SVG image list, and refers only to standard components. I removed almost all code also. Source.zip What is interesting: removing the bottom list view will stop the bug from occurring.

I like this 'feature' too. Imagine you would need to have a list of all definitions from all Delphi units (+all 3rd party code you use) to be able to create your own unique names. that would be crazy hard to find unique names. What would happen if you have your own TCustomizedPanel and use it all over your project... then Delphi adds same name to their code base. Or any other 3rd party code you want to use, ads it in next update. I think the full qualified name or unit used last in uses clause if good tradeoff.

I don't think so. This is a highly desirable feature to be able to use an existing indentifier. There are rules that the compiler follow. And as @Rollo62 said, you can always use fully qualified names to designate what you want to.

If you are interested in performance, http://kluug.net (Ondřej Pokorný) has two excellent libraries; the freeware OmniXML and the commercial OXml. I'm user and customer of OXml On this page: http://kluug.net/oxml.php choose the Performance tab and you will see a thorough comparision between most Delphi XML libraries. OXml shows about 10 times faster than MSXML I purchased both OXml and OExport, and quite happy with them Note: No, I'm not related to Kluug in any possible way, other than customer/user of his librtaries