[fpc-devel] System.UITypes and Lazarus

[Martin Frb]

On 09/02/2025 14:39, Bart via fpc-devel wrote:
> 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
> https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41300
>
> While this can be worked around, my question (no offense intended) it
> raises some questions in my head.
>


I haven't tested that, but maybe in Lazarus we can work around by 
simulating inheritance (it still will leave some caveats).

If you have in Systym.UITypes
     TFooOptions =(opt1, opt2);

Then you can have in Lazarus
     TLazFooOptions =(opt1, opt2, lazop1, lazopt2);

And the control/component in Lazarus would have a property of
     property Options: TLazFooOptions;


For streaming, "opt1" and "opt2" will be identifiers looked up against 
the type.
So, if an lfm (or other stream contains "opt1", that will load into a 
property of either type.

For in code handling, there could be an operator overload.

So if user-code uses (the enum member) "opt1" from TFooOptions, then it 
can still be assigned and compared.

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

Not sure what other new issues that might bring.... (other than a lot of 
work to maintain)

Lazarus units can ensure that the re-definitions have the same starting 
members (though that will be a long and ugly list)
{$IF ord(poPortrait) <> 0} {$ERROR fatal} {$ENDIF}
and also check for the "high()" value in fpc.

Unfortunately FPC does not seem to support full qualified inside the 
IFDEF. While all of those are valid
const
   x = TPrinterOrientation.poPortrait;
   y = system.UITypes.poPortrait;
   z = system.UITypes.TPrinterOrientation.poPortrait;
the qualified ones fail in the IFDEF (tested 3.2.3)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20250209/56ee9eb1/attachment.htm>