Sherlock

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

I believe Stefans words to be a fitting final statement on the subject of comments and suggest veering back to the subject at hand...namely refactoring 😉

Of course comments explaining every line of code are all in all useless. I'm talking about comments informing the uninformed reader what the heck is going on, and why a problem is solved this way and not another (hence preventing aforementioned refactoring odysseys). Most times those comments form the core of my technical file and only need a little fleshing out and graphs to be acceptable for auditors.

Well, clearly I'm not there yet, and neither is any of the folks whose code I've had the chance to read.

That's what comments are for. I don't see wisdom or a particularly high level of expertise in the words "Good code needs no comments, it is self explanatory".

@PeterPanettone: Though you try to put humor in your writing, I recommend one of two things: Take a deep breath before you begin to write a reply, imagine what others may read in that reply, how they might feel, if you would want to be addressed that way and most importantly, if it will have any positive impact on solving your issue Read your posts after writing them, then take a deep breath, delete all and rewrite according to option 1 Please don't get personal. No good will come of it.

I see issue 21814...I see no with. Both eyes open...Brain perhaps not at 100% though.

@Mike Torrettinni I hope you did not feel triggered by me. I am really interested in your use case. I have users, that simply don't care about IT, they are forced into using my software (healthcare professionals especially midwifes sometimes seem to have chosen their job, because they hoped to never use a computer). So I have to keep the error messages to a minimum, in very rare cases resulting in a painful process of almost restarting the complete application - unbeknownst to the user. Just so they don't find a reason to stop using the software, and believe me, they are looking for one all the time

I get it, I really do, but how do your customers catch incorrect results? And how do they know they are not getting incorrect results all of the time?

Well, not showing exceptions and eliminating exception handling altogether are two different pairs of shoes, are they not? Why not log into some %APPDATA% folder every bug, that occurs and try to keep the application running. When a bug does manage to get reported ask someone to send you the (doubtlessly numerous) log files. Apple for example highly discourages to display error messages in their iOS human interface guidelines. BUT they do encourage logging, and offer means to retrieve those logs from devices.

If you expect your customers to double check your results, why should they use your software in the first place?