Leaderboard

For new units you can enforce that with this registry setting (example for Delphi 10.3):

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.

Thanks god the new managements didn't kill all old references in code and IDE as first step, causing all kinds of weired issues.

New versions of compiler may use new functions in Windows API, that are not present in Windows 2000. So application will start and then complain about missing something (or start and immediatelly die silently).

I'm paranoid. Even for IDs expected to be in the million range I use UInt64 🙂

You can hexdump each compiler EXE to see which conditional symbols are actually available. That is what I do sometimes.

Problem very poorly explained at : https://quality.embarcadero.com/browse/RSP-21814 Please vote for it. Now we have seen many cases of this that customers have bought new computer and this setting has been on as default. And then at least our software stops working. Hope that you'll test this in on your own environments and products. and report your findings on that Ticket. I'll try to get on this also day, and report more exact findings. -Tee-

@Tommi Prami Just a hope. I haven't access to the 10.4 beta. Note: When UTF-8 is used as a default code page in Windows, if you use national characters in a AnsiChar constant, they should be encoded in #$nn format. Otherwise you'll get "W1061 Narrowing given WideChar constant (#$0401) to AnsiChar lost information". program AnsiCharConst; {$APPTYPE CONSOLE} {$R *.res} const AnsiCharYo1: AnsiChar = 'Ё'; AnsiCharYo2: AnsiChar = #$A8; // 'Ё' in ANSI 1251 Code Page; begin Writeln('#', Byte(AnsiCharYo1), ', #', Byte(AnsiCharYo2)); Readln; end. This program shows: "#129, #168".

https://quality.embarcadero.com/browse/RSP-15589

I have just write a little command line utility to convert your ANSI file to UTF-8. https://github.com/Kryuski/AnsiToUtf8

This could use a QP to expose it in the regular Options dialogs.

Yes, if you can't specify the actual TKey/TValue Generic parameters up front at compile-time when defining how you access the dictionary object from the Sytem.Rtti.TValue record. In which case, you can't use a standard "for..in" loop to enumerate the dictionary. All the necessary type information is lost once you access the dictionary object via the System.Rtti.TValue record if you can't type-cast the object. So yes, this is the only way I can think to enumerate the dictionary object using only RTTI and not caring what the actual Generic parameters are. I mean, if you really needed the RTTI for those types, you could take the dictionary object's ClassName() string, parse the typenames between the angle brackets, and resolve them using TRttiContext.FindType(), but that won't help you to enumerate the dictionary at all since you still need access to its enumerators (either via its GetEnumerator() method or its Keys+Values properties). I really couldn't say. Probably not, if you use the RTTI correctly and handle the enumeration correctly. Hopefully the RTTI and Sytem.Rtti.TValue record will handle the complexities for you. It doesn't, outside of the implementation code for the TDictionary class, where the TKey and TValue Generic parameters have meaning. Outside of the class, they don't exist. They are part of the class type itself, for instance TDictionary<string, int> and TDictionary<int, char> are separate and distinct types with no relation to each other. No. {$HPPEMIT} has no effect whatsoever on how the Delphi compiler processes code. {$HPPEMIT} merely outputs an arbitrary line of text to a C++ .hpp header file, if one is being generated while the Delphi compiler is parsing the code. Curious - what version of Delphi are you using? I have RTL sources up to XE3, and there are no {$HPPEMIT} statements at all in System.Generics.Collections.pas in those versions, so it must be something added in more recent versions.

Don't use date as string in SQL filters. Pass dates as parameters. That calendar component should give you the date as TDate or something, not string.

@Fr0sT.Brutal If you have nothing substantial to contribute to a users topic please refrain from posting.

Been experimenting with it myself and there are things I like. I will give a full report on it once they address some things I reported.