Leaderboard

No. It is a remnant from Delphi's pre-Unicode days (going all the way back to Delphi 5, if not earlier). Even then, I question why it was ever added in the first place, since the API always returned the correct sizes to begin with. So, this will cause the caller to unnecessarily waste memory (if they enumerate subkey/value names afterwards) and should be taken out. Yes. The increment is not necessary. I have filed a bug report: RSP-41787: TRegistry.GetKeyInfo() doubles size of MaxSubKeyLen and MaxValueLen

Hi All, is there is any documentation or books for firedac that help me to upgrade my knowledge? I look for FireDAC in Depth, but I found the most topics on fdmemorytable, and there is nothing deep. and the Embarcadero documentations and samples are very bad and complex, there is no explains enough. I have recordesd many videos on youtube and I feel that I am not strong enough in FireDAC. so, what is the solution?

FarEast is always true on Delphi x Windows:

So this is just a private protocol, not really REST. Commonly, textual responses are followed by CRLF, that may be what the client is expecting. Angus

Data display => locale-dependent Data exchange => hardcoded

@Attila Kovacs All Windows versions from Windows NT up to the current have Win32Platform = VER_PLATFORM_WIN32_NT. Other possible values are Win32s and Windows 95.

If that is the requirement, then, yes, setting global FormatSettings variable will have that effect. You also need to change Application.UpdateFormatSettings to false, before you change global FormatSettings to avoid user changes to be applied if the application is already running. You also need to keep in mind that any code that does not use global FormatSettings will not be affected by changes in global variable. For instance Delphi JSON serialization uses fixed settings for serialization that are based on JSON format requirements. Any code that uses own settings will behave in similar way. I would still suggest that for serialization purpose and data persistence, you use separate FormatSettings variable as if (and when) specification changes and users are allowed to have their preferer format used for viewing purposes, it will be very hard to make separation afterwards and find all the places that need to use specific fixed format.

In that case assign the buffer to nil (which is silence) and try again. However an av will never happen unless the API is wrong translated or when you use sloppy code. You will always get an HResult when something goes wrong.

I talked about it, not many peoples says that it is deep and it not cover a many topics, only few

I'd say C++ is definitely not suited to this programming.

Checking the results of the media foundation methods is as easy as can be. The results will give you information about what went wrong in most cases. So, the standard exception handling in Delphi is not suitable and therefore you have to write our own exception handlers, because each hresult code is described in WinApi.WinError.pas or WinApi.MediaFoundationApi.MfError.pas and will exactly return what went wrong. Media Foundation and related API's are not part of the Delphi distributions from Embarcadero, and if they are, they are outdated in most cases. The Microsoft documentation explains the retuned values of the API methods very well.