<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Luca Olivetti via lazarus <<a href="mailto:lazarus@lists.lazarus-ide.org">lazarus@lists.lazarus-ide.org</a>> schrieb am Di., 26. Feb. 2019, 09:34:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El 21/7/18 a les 18:26, Sven Barth via Lazarus ha escrit:<br>
<br>
>> !! :)<br>
> There are definitely still some problems with it, e.g. a field of type <br>
> TObject (or any descendant) currently can't be deserialized as I didn't <br>
> want to rewrite DeStreamClassProperty. Then there are the sets which for <br>
> non-published properties can be greater than 32-bit (up to 256-bit <br>
> currently). Support for dynamic arrays could be added as well.<br>
> Also I didn't check whether all types serialize/deserialize correctly, <br>
> e.g. especially the special floating point types Comp and Currency. <br>
> You'd need to check what Get-/SetFloatProp are doing there.<br>
<br>
I tested this unit and I see that it doesn't manage bitpacked records <br>
inside the record, and the field names are "Field1", "Field2", etc.<br>
(I wanted to test what happens if I add fields to a record then try to <br>
deserialize into it a previously serialized version, but without real <br>
field names I suppose that wouldn't work properly).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I didn't test bitbacked records so those might indeed fail. </div><div dir="auto">And field names are currently not available. This would require the extended RTTI which is still work-in-progress. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>