Fr0sT.Brutal

mii := Default(MENUITEMINFO);

Side note: if you don't have to support old compilers, using Default() intrinsic instead of ZeroMemory is less error-prone.

I find "Project options > Compiler > Code page" setting very useful. Though newer versions seem to not need it anymore

Sure. In some cases could be useful Abort instead of Exit together with on E: EAbort do {ignore} or extracting these checks into nested subroutine where natural Exits could be used

If that's a text editor, it should have some encoding guessing heuristics or manual setting. Anyway editors should just suppose UTF8 by default so that these tricky ANSI codepages go into history. UTF8 was designed so that for latin char set it is 100% identical to ASCII encoding and most of older tools that take single-byte encodings could work without modifications (of course, those which deal with char-by-char tokenization or string content processing will need modification anyway but that's a minor part - at least in all my projects I almost never had a requirement to know whether a string is UTF8 or whatever). BOM obviously breaks this compatibility; moreover, it turns a "plain text" file into something with invisible header so that "empty file" <> "file of 0 bytes" anymore.

This has come from web, I guess. It's a very frequent pattern there

That's weird - can't reproduce this issue. VTVersion = '7.3.0';

I like the idea!

Meanwhile BoolToStr returns '-1' for True %-) "finally" sections are good for making early exits that must not exit the subroutine

I guess you meant "Congratulations LLVM team!" 🙂

First, nothing in TDateTime could be "local". It's just the same shift from some constant point as any other timestamp. It's up to client app to generate this shift either in local timezone or in UTC (which is what I always recommend, just like UTF8 in string encoding). Second, there are TIMESTAMP_WITH_TIMEZONE type in most of DB engines. It requires some additional handling though and not mapped as-is to TDateTime for obvious reasons. Just like most of web-sites behave today. "We determined your city as %CityName, is that correct?" and leave ability to set whatever other city user wants

Fortunately we have sources of RTL so some of these issues could be fixed.

*scratching my head* any database internally uses its own timestamp format that converts without problems to Delphi TDateTime by DB libs. I see no sense in replacing this mechanism by custom one that only your apps know how to deal with, so f.ex. examining table data with an admin tool becomes a real pain.

ANDROID & CPUARM64 ?

Those who use chars > #127 in AnsiChar constant are digging a trap for themselves anyway. I think this option is a good reason to check usage of Ansi encodings in projects. BTW, I recently found a very sly bug caused by ACP that only revealed itself on a system with an ACP different than expected. Luckily the check for reproducibility didn't require any OS change, just setting System.DefaultSystemCodePage to another value.

Regarding BOM support https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows#Programming_platforms

Interesting option. I wonder what it changes from the app's POV. I doubt ancient apps will be able to use Unicode flawlessly even with this option.

Yes. So just get the date from Calendar locally as Tdatetime or TIMESTAMP or whatever and send it to DB using parameters. Otherwise

Aha! That's the very issue! And I'd say you trying to cure a consequence instead of a cause. One of developer rules I discovered is to NEVER ever rely on any regional settings other than for displaying purposes. Especially where any kind of communication between two PCs involved. In your case, DB should never accept or send a timestamp as a string. Just never. If there's no such ability, just carve timestamp format in stone and use it everywhere for internal communication. Of course, for display purposes use local settings (f.ex., American mm/dd/yy format makes other people crazy). @Sherlock it wasn't clear enough

If a class requires pretty much parameters being set to operate correctly, there's not much to do but call constr with some params and then init the object some more before running its methods. After turning on ignition, driver has to release handbrake and switch to drive mode anyway. Alternative is using a record with full set of required values as constr parameter but it causes some other gotchas.

You mean, you want a relation between Country name and app's locale? Why not use the system's locale? If your customer is Chinese living in Australia (I heard there are many) he probably wants Chinese labels not English. I'd let user decide what language he prefers.

I FINALLY got it! Your posts with sudden UPPERCASES remind me balloons in comics. You should use proper comic FONT as well xD

I'm unsure... probably that's not the proper task for Hex viewer Pretty nice one! Alas it's shareware

I'd start with all platforms in a single unit but split it as you do if it grows larger

Samples are frequently just showing some features. They don't have to be examples of perfect design. +1 but I'd add "if possible". Surely one should estimate complexity of common interfaces and IFDEFed fragments. F.ex., IFDEFs in uses clause are hardly avoidable. But minimizing platform-specific IFDEFs (and other IFDEFS as well) should be the priority. Luckily with inlining wrapping platform-specific code into a common routine even won't cause a performance hit. Anyway separating platform-dependent and platform-independent code is nice and useful exercise. F.ex., one could discover that full file paths may contain no drive letters, or libs may have extensions other than "DLL", or that handy PostThreadMessage function is missing xD