<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 09/02/2025 14:39, Bart via fpc-devel
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMye31w-h9-AetteS0QjvUe7-0gTbg=8j3+Cbs8doG7s+sxqBA@mail.gmail.com">
<pre wrap="" class="moz-quote-pre">Hi,
The Delphi compatible unit System.UITypes is getting out of sync with Lazarus.
The reason for this is twofold:
1. the faster release cycle of Lazarus
2. the fact that Lazarus supports more widgetsets, for which we also
need enumerations, and Delphi does not have these.
This can lead to errors as described in
<a class="moz-txt-link-freetext" href="https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41300">https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41300</a>
While this can be worked around, my question (no offense intended) it
raises some questions in my head.
</pre>
</blockquote>
<br>
<br>
I haven't tested that, but maybe in Lazarus we can work around by
simulating inheritance (it still will leave some caveats).<br>
<br>
If you have in Systym.UITypes<br>
TFooOptions =(opt1, opt2);<br>
<br>
Then you can have in Lazarus<br>
TLazFooOptions =(opt1, opt2, lazop1, lazopt2);<br>
<br>
And the control/component in Lazarus would have a property of <br>
property Options: TLazFooOptions;<br>
<br>
<br>
For streaming, "opt1" and "opt2" will be identifiers looked up
against the type.<br>
So, if an lfm (or other stream contains "opt1", that will load into
a property of either type.<br>
<br>
For in code handling, there could be an operator overload.<br>
<br>
So if user-code uses (the enum member) "opt1" from TFooOptions, then
it can still be assigned and compared.<br>
<br>
If user-code has a variable "MyOptsStore: TFooOptions" that works...
except, when the TLazFooOptions property has one of the lazarus only
values. => that can only be caught as runtime exception.<br>
Or there is no operator in that direction => which would mean the
user can use the enum members from UITypes, but not the enum type
itself.<br>
<br>
Not sure what other new issues that might bring.... (other than a
lot of work to maintain)<br>
<br>
Lazarus units can ensure that the re-definitions have the same
starting members (though that will be a long and ugly list)<br>
{$IF ord(poPortrait) <> 0} {$ERROR fatal} {$ENDIF}<br>
and also check for the "high()" value in fpc.<br>
<br>
Unfortunately FPC does not seem to support full qualified inside the
IFDEF. While all of those are valid<br>
const<br>
x = TPrinterOrientation.poPortrait;<br>
y = system.UITypes.poPortrait;<br>
z = system.UITypes.TPrinterOrientation.poPortrait;<br>
the qualified ones fail in the IFDEF (tested 3.2.3)<br>
</body>
</html>