Leaderboard

I've now added the code and demo (with documentation!) for what I have been using as a replacement, here.

I add to this discussion (which talks about formats in INI files) that a problem similar to that of the date also exists in the writing and reading of float values (i.e. numbers with decimal points). It is necessary to use the TFormatSettings and set the correct values (which are those of the files and not of the language). The example is when you go to write a value in an environment set in Italian (where the "comma" is the decimal separation sign) and perhaps then read it in an environment set in English (where instead it is the "dot "). I override ReadFloat and WriteFloat of TIniFile to correct that to always read and write the right values. Of course it is for compatibility and maintenance of the old programs, the new ones use a local database to store the data.

When I look at that .ini file, there is a Unicode character U+202F (Narrow No-Break Space) in between "11:15:12" and "AM". I think TryStrToDateTime() only supports the ASCII space character U+0020, so likely can't handle that other type of space character and so fails the parse.

Yes: Install v23.2.3 There is no "workaround". To support Delphi 12 with an older version you would have to replicate the things they've done in 23.2 and then you might as well just install 23.2

I need to provide some documentation, but I have this: https://github.com/DelphiWorlds/Kastri/tree/master/Demos/macOSStatusBar Also be aware that I personally use another variation of this because I had trouble with "dynamic" items when associating them with FMX menu items - it became easier to just forget FMX menu items entirely, though there's a bit more code involved. I can share that code later.

Ah! Stupid me, that joke went right over my head, I didn't even notice the 13 🤯

You mean this one line?

The irony about this is that to build a RAD application you are using components that are by design loosely coupled and more or less easily testable in isolation. The issue starts with non-UI-related code written directly into UI control event handlers and accessing global states such as these global form variables. If one would write their RAD application also in a component-driven architecture, things would be way easier - but slapping code into event handlers is quick at first and a nightmare to maintain later.

When you need to know, use SizeOf. If you must know before you compile, use a packed record. If you care about the memory size of these records it is probably due to concerns about size constraints, in which case a packed record will guarantee the smallest possible size based on the field types. If that is not what you're concerned about, it's hard to know why you want to "predict" the record size, and so SizeOf is reliable and will suffice for any needs in code (pointer arithmetic, etc.).

Thanks, I'll look at this when I get back to ICS next week. Note, there is an ICS forum for future support, but you don't need to repost this topic. Angus