Sherlock

So you trust inline variables to work flawlessly and use them wherever you like? You trust the TParallel lib?

That looks pretty cool. I don't know why, but I thought you where on a PC. But still the loading should be possible in a thread, where you can also prepare almost all the objects needed, and in the end just assign them to the main thread (synchronized!)

Load them in a thread, but don't expect speedup unless every single texture is stored on its own hard drive. You should also generate an AnimationBitmap object for each loaded image, and once the thread is done, or it once it needs to be used be used, synchronized assign it to the main thread BitmapListAnimation.

Just load it all at application or scene start. How large can those sprites be? It's a game, you may waste resources, it's kind of being expected anyway.

You either mean management reports or manged records... not sure which. Hmmmmm

Sorry, boss.

Wait a minute. A client should use a random port. Only the server needs fixed ports. So in theory you should be able to open thousands of http.Get in parallel. Do you set your client to use a fixed port as well?

That's me

Well luckily this is not a Cobol forum - no wait, even that will not die (german article on 60 years of Cobol: https://www.heise.de/developer/meldung/60-Jahre-COBOL-Die-Sprache-die-nicht-totzukriegen-ist-4518334.html) Then another surely dead language maybe, let's try Fortran ... oops, not dead (https://www.vortech.nl/en/fortran-is-alive/). TL;DR: Don't make unsustainable claims. 😉

I'm looking forward to a ton of bug fixes and performance improvements, for the IDE, the compiler(s) and the resulting executables. Considering the code name "Denali" is based on a mountain in Alaska a feature freeze could sound likely, but I doubt it. When Delphi Anchorage is finally released it will have some cool new features along with the obligatory cool new bugs... *Sigh*

Wait. What? Megabytes? Really? I do recall W2k being quite thrifty with memory but that does not sound very likely.

This SO topic should point you in the right direction: https://stackoverflow.com/questions/28329185/how-to-prevent-screen-lock-on-my-application-with-swift-on-ios

As an expansion to that, what code should have is a comment explaining the why.

I actually never heeded the warnings my FMX code generated when in ARC mode. I need Windows as well so...good on me, for once.

So do I. And I concede, that I should have mentioned FMX in my blanket statement. For VCL changes are quite rare, especially in "same name" releases (i.e. 10.3.2 -> 10.3.3).

When given the option to upgrade: Upgrade. Every single version. The individual steps between versions are not that big. We will most likely not be facing a brute like the Unicode disaster (in my eyes) like back in the day. @David Schwartz: I seriously have to wonder, what needs to be done between Tokyo and Rio. In my (albeit not very broad) experience there should be nothing to do at all, except when using FMX, but then FMX forces to update anyway. Sherlock

Done

How sure do you have to be, that the signature is real? It is quite easy to let someone draw his signature in a TPaintbox, and then store the image as a BLOB in the DB. But if you need to make sure, this signature is real, then you would have to store the dynamics of its creation. That is tricky.

I personally know of two companies in my field of work (medical software), that have killed themselves over the "simple" task of moving from "some old outdated" language to C#. Both companies have enjoyed the questionable pleasure of being tutored by MS consultants. What everybody involved forgot, is the amount of customizing that went into the software for some special really needy customers - customizing, that went unnoticed or at least undocumented. So a bunch of features, and I mean a really big bunch, did not end up in the painfully created C# versions of their software, and the customers simply left. Because it got more expensive as well. And then from the customers POV it's just simple math: less features + more cost = bye bye. Now both of those companies have been bought for a penny and a dime by the one I was in at the time. And constant rumors of the need to move to C# with our divisions software kept rolling around...but never became true (someone at the top must have learned something). New projects where done in other languages, but that is totally OK.

Now please don't do that! I would say, that is a bit of an overreaction.

This is not the final name for the thread, it's just all I came up with in my ignorance. I am open for improvements.

So, if anyone would like to contribute something to this topic, stay here, you're good. If you have something to say about umm... Hashing Dictionaries and such, this is not the place to be While you weren't looking it got split to here:

OK, I'll try to fork it then. Lemme see now, where did I put my magic wand?

So I wanted to set the layout to the way I'm used to from Tokyo and got everything right and stored it into the "Standard-Layout" via the Moon Symbol in the title bar (strange, but as long as it works...). After restarting Delphi, it gets almost everything right, except for one thing: the side panels are way to narrow. No matter how wide I store them, they end up being the seem narrowness. And the object inspector wont store the separator position (the line between property and value) either. What am I missing, where and how can I fix this?

Soooo, I know I am not free of guilt either , but nevertheless, how about a nice swerve back to the topic please? And as a reminder, the topic is "As a Delphi expert, do you ever need to refactor or improve your code?" If there is an interest to further the discussion on dictionaries, I am happy to break the forum by trying to fork that discussion