Leaderboard

Your interposer is effectively useless. When you call CardPanel.AddNewCard an instance of Vcl.WinXPanels.TCard is returned. No amount of casting can change that. You are just telling a big fat lie to the compiler. If you use as to cast then you will find out the runtime truth. They issue here is that you are trying to change the instantiated type of the cards. But declaring a new type of card doesn't achieve that since that code lives in the panel class. It's therefore the behaviour of the panel class that you need to modify. In order to get your card types created you should override GetCardClass. http://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.WinXPanels.TCustomCardPanel.GetCardClass You could do that with an interposer for TCardPanel. However, I wonder if perhaps the right thing to do is to stop using GUI controls to store data. GUI controls present data. They should not have knowledge of that data. Code outside of the control should be in charge of that.

I agree with specific intent part. Not necessarily with always measuring (but this has tendency to push discussion in wrong direction). Measuring performance bottlenecks is important, but once you know that particular construct can cause bottleneck, you might want to avoid using it in performance critical code, even though you will not exactly measure how much of bottleneck that construct really is in that particular code. In other words, life is too short to measure everything, sometimes you just use what you know is the fastest code (with all downsides considered). I am using Items, when I am iterating over small collections in non-critical code. Yes, exposing internals is not the best practice in general. In case of TList it is necessary sacrifice because performance requires it. Why not something else - well you can use something else, but you are out of option when core RTL/VCL/FMX frameworks are concerned. For instance speed optimization of FMX framework described in https://dalijap.blogspot.com/2018/01/optimizing-arc-with-unsafe-references.html includes direct array access and using List property. With that optimization in just few places I got from "it barely scrolls" to "fast scrolling" on mobile applications. Yes, ARC also had huge impact in this case, but even without ARC compiler, you can still get better GUI performance on mobile apps with such optimization, and on low end devices every millisecond counts.

Right now there are only 25 topics per page, displayed in forums. Is it possible to add 'Show all topics' or perhaps options to show 100, 200... topics per 1 page? The forum is becoming really useful resource, but it's quite annoying to have to go page by page back to find older topics. I'm referring to this navigation on top of each forum: Show All or Show 100/200/500... per page would be very useful. If Show all is possible, I don't mind waiting to load. I appreciate even considering this request. Thanks!

As @Dalija Prasnikar explained sometimes you are not after super-duper micro optimization, but if something is standing out you try with simple optimization. Here is example that triggered this topic: I started with For..in loop and accessing data the 'correct way' (without .List), the method took almost 3s: I changed to for i := 0 to Count - 1, the execution time dropped by 60%: And this is execution time accessing data thought .List: a 99% reduced execution time: The whole method dropped from almost 20% of whole execution process time, to just 0.15%. I would say this a very valid reason to access items directly, through .List. OK, for context, this only came to light after one of the customer's data set came to be 10x bigger than what was thought was the biggest data set. So, the original method was working good and at acceptable performance, but it failed miserably when 1 customer went rogue.

I think OP's takeaway was to use direct array access always. I'd say use it with specific intent only. I'm dead against TList exposing its internal implementation details like that. Anyway, the Delphi collection classes have been such a mess over the years with so many bugs I gave up on them a long time ago and use my own collection library. If you can't do that then it's hard to see past spring's collections.

@Daniel I hope this is better This is an IDE expert problem

Famous last woAccess Violation at address $00000000 ...

Probably a bad idea. I would only do this in specific instances where you have timed your program and identified a bottleneck.

That's a false goal. Remove that goal from your life. Following it will be making your code worse.

I can reproduce it, but I have no idea why this is the case. I suppose it has nothing to do with GIF files, the 2nd TWebBrowser just doesn't get repainted. If you resize your window you see how portions of the 2nd browser view will get repainted.