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.

First:
Why the need for such a unit?
IOW: what is the use-case for needing the enumerations out to the unit where they ar actually used (and were defined to begin with)?

Second:
Given the fact that enumerations like TOpenOption etc. are related to GUI applications, why does this unit "reside" in fpc and not in Lazarus?

Op 9-2-2025 om 14:39 schreef Bart via fpc-devel:

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

(a bit extreme at the moment, but hopefully that will improve in the future)

Primarily compatibility, but there are reasons why it is a good thing.

Two fold.

- Non LCL libraries (like e.g. FMX or a clone)  might use them, since that is why Delphi did it.

- Less specific for the enumerations, but having e.g. the Tcolor(rec) related stuff in LCL unit was a pain, as e.g. FCL-image needed it for non visual image manipulation

So, compatibility.  The pain is now a bit harder since the unit pretty much got filled up in a long release hiatus. But let's assume that that is temporary.

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)

Because it transcends the LCL or any widgetset out there:

Delphi has this unit to offer a common set of types for the VCL and FMX GUI frameworks.

The primary purpose to have it in FPC is Delphi compatibility, and in particular to be able to compile FMX applications (which is now possible).

We can try to enhance it with things needed by Lazarus, but it should never move to Lazarus, that would go against its purpose.

Michael.

The primary purpose to have it in FPC is Delphi compatibility, and in particular to be able to compile FMX applications (which is now possible). We can try to enhance it with things needed by Lazarus,

That's nice.

but it should never move to Lazarus, that would go against its purpose.

OK.