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).

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.