Leaderboard

I can reproduce the issue. Interestingly, if you don't use the TRttiContext and just assign the ColorProp directly to the TValue then TValue.ToString() works as expected: //Val := AColorProp.GetValue(ColorObj); Val := ColorObj.ColorProp; // Val.ToString now returns '4294303411' In both cases, the numeric value (inside the TValue.FAsULong field) is correct, but the RTTI for the value different - in the first case, the TValue.FTypeInfo belongs to TAlphaColor, but in the second case the TValue.FTypeInfo belongs to Cardinal instead! Both RTTIs have Kind=tkInteger and OrdType=otULong, so the numeric value is stored in TValue.FAsULong and TValue.ToString() formats as a UInt64. But, the TValue.AsUInt64 property getter behaves differently on the two RTTI types: function TValue.AsUInt64: UInt64; begin if not IsEmpty then begin if FTypeInfo = System.TypeInfo(Int64) then Exit(FAsSInt64) else if FTypeInfo = System.TypeInfo(UInt64) then Exit(FAsUInt64) else if FTypeInfo = System.TypeInfo(Cardinal) then Exit(FAsULong) // <-- SECOND CASE else if FTypeInfo^.Kind = tkInteger then Exit(AsInteger); // <-- FIRST CASE end; AsTypeInternal(Result, System.TypeInfo(UInt64)); end; function TValue.AsInteger: Integer; begin if not IsEmpty then begin if FTypeInfo = System.TypeInfo(Integer) then Exit(FAsSLong) else if FTypeInfo^.Kind = tkInteger then case GetTypeData(FTypeInfo)^.OrdType of otSByte: Exit(FAsSByte); otSWord: Exit(FAsSWord); otSLong: Exit(FAsSLong); else Exit(FAsULong); // <-- FIRST CASE end; end; AsTypeInternal(Result, System.TypeInfo(Integer)); end; In the first case, TValue.FTypeInfo does not belong to either UInt64 or Cardinal (it belongs to TAlphaColor), so the TValue.FAsULong field (whose unsigned value is 4294303411, hex $FFF5DEB3) first gets converted to a signed Integer, resulting in a negative value of -663885 (hex $FFF5DEB3), which is then converted up to a sign-extended UInt64, resulting in a large unsigned value of 18446744073708887731 (hex $FFFFFFFFFFF5DEB3). In the second case, the TValue.FTypeInfo belongs to Cardinal (an unsigned type), so the TValue.FAsUlong field (hex $FFF5DEB3) is converted as-is to a zero-extended UInt64, preserving the original value (hex $00000000FFF5DEB3).

I have a problem with my DataSnap client application on Android 11 OS. Not every time but from time to time and on different places in my code. Sometimes I recive this message When i click Break debuger points on this line in code What can be a problem

This example application launches a local web server and requests an access token from Microsoft Entra ID (formerly known as Azure Active Directory (Azure AD)). The access token then is shown in a web page together with a button, which allows to request a new access token. Location: https://github.com/michaelJustin/daraja-framework/tree/master/demo/16_entra_refresh_token Requirements Daraja HTTP Server Framework Indy 10.6.3 (https://github.com/IndySockets) OpenSSL DLLs for Indy (https://github.com/IndySockets/OpenSSL-Binaries) Delphi 2009+ or Lazarus / FPC 3.2 Note: the example code contains the configuration for an existing Microsoft Entra App registration. You may configure it to use a different App registration, by modifying the constants in unit MainUnit. Please note that the App registration must be configured as "Mobile and desktop application". Security considerations The example code uses response_mode=form_post to receive the access token. Unlike with response_mode=fragment (or query), the browser does not receive the access_token parameter in the redirect request URI. Therefore, the access_token is not accessible within the browser's memory. ("Implicit Flow with Form Post") The example code uses PKCE, which stands for "Proof of Key Code Exchange", an extension of the OAuth 2.0 protocol that helps prevent code interception attacks. More information GitHub: https://github.com/michaelJustin/daraja-framework API documentation: http://michaeljustin.github.io/daraja-framework/

The predictive suggestions is an OS feature, the STYLED recreate the memo feature instead of PLATFORM. No complaints here, but I have not enough Mac&iOS users to complain with a broken Apple feature which suggest wrong or strange words and replace good once by others in French.

I don't have any basis for my pessimism other than my experience with these kinds of things. Oh I definitely expect that to be the case for me.

I'm seeing this more and more lately. It is very worrisome that people actually think these autocomplete engines are authoritative and will actually argue with you if you present facts that disagree with the text generated by these tools. They may have their uses, but this is borderline scary.