Leaderboard

I answered your same question on StackOverflow before seeing it posted here too: https://stackoverflow.com/a/79151906/65863 I see you actually posted this same question on 3 forums at the same time: Delphi-PRAXiS, StackOverflow, and Lazarus. It's generally considered rude to ask the same question on multiple forums at the same time. It gives people the impression that you are in a hurry and don't value any given forum, and you'll usually get similar answers, and you lessen the value of people duplicating their efforts. Pick a forum, give it some time to amswer (like a few days at least), and if you don't get a satisfactory answer then try another forum if needed.

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

@Jim McKeeth has updated the GExperts documentation a bit. It’s far from finished but that’s better than the totally outdated one on gexperts.org. I have now exported it as webhelp and checked it in to subversion. You can read it at my newly created domain help.gexperts.de. (The domain is temporary only for now. I got it cheap but I’m not sure I will keep it.)

TMS BIZ, based on very fast http.sys-driver. https://www.tmssoftware.com/site/tmsbiz.asp

Yes, it works now. Thank you.

It is not possible to define TCustomContainer<T: TCustomItem> if TCustomItem is its internal public type. This only compiles (up to your error) because there is another TCustomItem defined outside that class. Doing this with classes only is impossible. You cannot have both a T that is a TCustomItem within TCustomContainer<T> and a FContainer that is a TCustomContainer<T> within TCustomItem. The relation cannot be bi-directional in this scenario. A closer implementation to what you're trying to achieve is possible with interfaces, but that comes with its own set of issues. This post has an example of what you're trying to achieve with interfaces: Also, IMO it is not a good idea to couple your classes like you're trying to do here. A TCustomItem should not directly call the TCustomContainer's HandleItemNotification; you should handle that either via an observer pattern or with events.

The problem is that all variants of IGenericList<T> have same GUID so Supports function will succeed even though those different generic lists are not compatible.