Remy Lebeau

The coder who previously worked on Indy's OpenSSL's support has been MIA for a long time. Any new updates will have to go through me, and I just haven't had any time to do it myself.

Right, such examples are using [in] and [out] only for function parameters, not for record fields like in efortier's example. I've never seen such attributes used on fields.

That is because there are two problems in your code: the JSON string you are passing in to ParseJSONValue() does not represent a JSON object, just a single JSON name/value pair, so your first typecast to TJSONObject will fail. You need to wrap the entire JSON string in angle brackets, since ParseJSONValue() can't return a TJSONPair. The "PROFILE" field is not a JSON array, so your typecast to TJSONArray will fail. The "PROFILE" field is a JSON object instead, so you need to typecast to TJSONObject. Try this instead: procedure TCLOSINGForm.SpeedButton10Click(Sender: TObject); var JsonValue: TJSONValue; JsonObject: TJSONObject; Branch, st: string; begin st := '{iWN5p2qfRFeGKXn1m3iGnDW0Vkl2: {"PROFILE":{"BIRTHDAY":"8\/20\/19","FULL NAME":"","GENDER":"MALE","NATIONALITY":"INDONESIA","NICK NAME":"","OFFICE":"CLOSING SYSTEM","PHONE NO":"","REFERAL UID":"","WEDDING":"8\/20\/19"}}}'; JsonValue := TJSONObject.ParseJSONValue(st); if JsonValue <> nil then try JsonObject := JsonValue as TJSONObject; JsonObject := JsonObject.GetValue('iWN5p2qfRFeGKXn1m3iGnDW0Vkl2') as TJSONObject; JsonObject := JsonObject.GetValue('PROFILE') as TJSONObject; Branch := JsonObject.GetValue('BIRTHDAY').Value; mem.Lines.Add('Parsed BIRTHDAY ' + Branch); Branch := JsonObject.GetValue('FULL NAME').Value; mem.Lines.Add('Parsed FULL NAME ' + Branch); finally JsonValue.Free; end; end;

Correct.

That was posted before I saw Embarcadero had made a deal with Google to offer an extension for apps written in Delphi/C++Builder. Obviously, you should go that route instead.

That was XP, when Visual Styles were first introduced. Doubtful. What you are thinking of is the app manifest needed to enable ComCtrl32.dll v6 so Visual Styles work. Without the manifest, the system default ComCtrl32.dll version is used instead. 4.70 was the version shipped in Win95. XP and later have shipped with 5.82 and 6.x. More likely, there is simply a logic bug in the offending component, either it is not initializing ComCtrl32 correctly, or it is not detecting the active ComCtrl32 version number correctly.

What does the call stack look like when the exception is raised?

Ancient. Yes, the IdObjs and IdSys units were removed from Indy well over a decade ago. Any code that references them is severely outdated and needs to be updated to a modern version. The GitHub repository is just a mirror, the real repository is still on SVN instead. So the Git history may not have everything. When the IdObjs/IdSy units were removed, TIdThreadList was replaced with the RTL's standard TThreadList (and various other compatibility classes were likewise replaced with standard equivalents - TIdStrings -> TStrings, etc).

Interesting reading: http://www.fmxexpress.com/learn-how-to-deploy-delphi-10-3-rio-android-apps-to-google-play-with-android-64-bit-requirements/

https://community.idera.com/developer-tools/b/blog/posts/additional-information-for-the-android-32-bit-extension

Note, there are a lot more ComponentPlatforms values available than just those shown above: pidAllPlatforms (new in 10.3.2!) pidWin32 pidWin64 pidOSX32 pidiOSSimulator32/pidiOSSimulator pidAndroid32Arm/pidAndroid pidLinux32 pidiOSDevice32/pidiOSDevice pidLinux64 pidWinNX32 pidWinIoT32 pidiOSDevice64 pidWinARM32/pidWinARM pidOSXNX64/pidOSX64 pidLinux32Arm pidLinux64Arm pidAndroid64Arm/pidAndroid64 pidiOSSimulator64

For those of us that don't use this feature yet - what happened?

Also: https://community.idera.com/developer-tools/b/blog/posts/additional-information-for-the-android-32-bit-extension

Indy has StrInternetToDateTime() and GMTToLocalDateTime() functions in its IdGlobalProtocols unit which support both of those formats.

You have to be careful with WaitForInputIdle(), though: WaitForInputIdle should really be called WaitForProcessStartupComplete WaitForInputIdle waits for any thread, which might not be the thread you care about

Between the time you check connectivity and the time you want to send an email, your Internet connection may go down, or the Internet may encounter problems (DNS outages, DOS attacks, etc), or the server may go into maintenance mode, or .... So, there is no real benefit to checking the connection ahead of time. Simply attempt the connection at the time you actually want to send the email, and handle any errors that may occur at that time. That is your simplest and best option.

The DocWiki is correct. Generics are not supported on interface methods. Nor does it make sense to allow that anyway. The main reasons to use interfaces are polymorphism and predictable functionality contracts. If two classes implement the same interface, but they implement the same methods using different parameter/return types, then polymorphism and contracts go out the window. There is no viable use-case where allowing Generics on interface methods makes sense. No. Why do you think you need this? You don't. Find another design.

You didn't answer my question: "So, have you looked at the implementation code that is meant to run on Androidd 6.0+? Does THAT code call AOnDisplayRationale as expected?"

You and I don't agree on much very often, but we can agree on this point. For instance, I'm a programmer, who happens to work primarily in C++ and Delphi, but I will reach into Java and C# and even VB and Assembly when a task requires it. I think in terms of logic and tasks, and then write specific code in the syntax of whatever language I'm working with at the time to accomplish those things. Programming is programming, differences between various languages are just a matter of syntax and libraries available.

Andreas just released a new Fix Pack update for 10.3.2: https://www.idefixpack.de/blog/2019/07/ide-fix-pack-6-4-3-for-delphi-10-3-2/

Perhaps. On the other hand, it turns out that the introduction of TFieldsCache in 10.3.2 has broken backwards compatibility with 10.3 RTM, so be careful:

That is what I get for not checking Delphi's pascal declarations before posting code examples.

That would only be needed if you are using Delphi Xe or earlier. In XE2 and later, you should use "Winapi.Windows". Though, you can omit the "Winapi" prefix if you have "Winapi" included in your project's "Unit scope names" list. Because I wasn't targeting any specific Delphi version. The code I suggested should work in older versions, too. Well, XE and later anyway, since 2010 and earlier did not have a version of FindCmdLineSwitch() that returns a string value, but that is not hard to write a manual replacement for if needed. "Windows" and "Winapi.Windows" are the same unit, so you can't "use" it twice in the same unit. The latter simply has a "Unit scope name" applied to it in XE2 and later.

Not specifically, someone will have to do a diff of the RTL source code between 10.3 and 10.3.2. All the release note says is "VCL DFM files loading optimization".

Just to nitpick - quality.embarcadero.com is for Quality Portal. Quality Central (qc.embarcadero.com) is dead.