Elements 10 Build Error within false conditional define: "class member expected but 'case' found"

Elements Oxygene
23

Unrelated/tangential question: Any specific reason why you’re using Oxygene only for Android, and not the other platforms? Anything we can improve to make it more feasible to support all platforms within Elements for your project?

—marc

1 Like
24

As far as exceptions within the compiler directive blocks, to expand on what @baatro posted above, adding a directive to the middle of a statement seems to generate an error in any setting. @baatro noted this in uses and type sections. I’ve also noticed it in a multiple variable definition as below:

var
	gDoneModal, 
{$IF NOT OXYGENE}
	gbRTFRegistered, 
{$ENDIF NOT OXYGENE}
	gbUSTLRegistered, gbFlavorTypeFormat, gbAccUnicodeFormat: Boolean;

In this specific case, this is in the interface section of the file.

25

At the moment it’s simple necessity. There’s not really any other viable option for using our FPC codebase with Android. We are hoping that Windows can move to Oxygene at some point in the future for .NET support.

Fully supporting FPC code. The Android app is a highly adapted version of our FPC codebase specifically designed to work with Oxygene, and it was a massive undertaking to make it work. We would love for Windows to have .NET support, but not at the expense of re-writing the code to work with Oxygene.

Honestly this issue with compiler directives is the biggest hurdle at the moment. If I’m getting 8500 build errors from it, the Windows code would probably be more like 40-50k build errors.

I can make a list of some other syntax issues we’ve experienced while bringing the FPC code into Oxygene if that would be helpful. Off the top of my head, these are some of the most pervasive changes we’ve been forced to make:

  • TChild = public object(TParent) changes to TChild = public class(TParent)
  • the otherwise keyword in a case statement (Oxygene only supports else)
  • destructor is not supported (it would be nice to have a compatibility option to simply treat this as an alias for method just so code changes don’t have to be made for every class)
  • requires the exit keyword for return values instead of FPC’s FunctionName := returnVal;

We’re in the process of moving away from NEW(TObject) syntax to TObject.Create to better support Oxygene, since Oxygene (thankfully) allows for this legacy syntax. This is partly for Android support for us but also in hopes that we can move Windows to Oxygene in the future.

I’d be happy to start a new thread with some of these syntax changes if that would be helpful.

1 Like
26

Note that the UseLegacyPreprocessor option, while it does prevent a lot of advanced functionality to be used, will be around long term. I’ll check with Carlo, but I’m sure we can commit to supporting in indefinitely (opposed to as a temporary migration-help workaround, as it was originally introduced as). That way, it would be a reasonable and valid decision on our side to just embrace that mode and plan to stay with-in it.

Very!

to be clear — Turbo/Borland Pascal (ahh, the good old days) used object before Delphi 1 introduced class. in FPC, does object behave as it did in TP/BP, or is it simply a different keyword but behaves same as Delphi’s class'? Does FPC not support class at all, does it treat the two keywords the same, or are there behavioral differences?

What does it do? same as else, or does it behave differently? Do you have a docs reference for this?

Destructors should work, in Delphi Compatibility mode?

Probably something we can allow in Delphi Compatibility mode (assign to function name, instead of assign to result or calling exit. That said, Does FPC support result, like Delphi does? If so, that’d be the preferred way to make this code workable between both compilers?

Please!

1 Like
27

From Object Oriented Programming with Free Pascal and Lazarus - Free Pascal wiki, it looks like they behave like TP/BP objects — ie stack based.

Would it be sufficient if object merely mapped to record (in Delphi Compatibility mode), given that records in Elements can have members and pretty mjuc behave like stack-based objects? I assume not, since I inheritance would be needed, as well.

Can you elaborate some more on when/why you use objects instead of classes? When Delphi switched to Classes, they pretty much just deprecated the old object type, and I don’t recall that being a big problem “back then”, in the sense that there really was not good reason to use both models, and classes did everything objects did, except saving you to define extra PX = ^TX type aliases.

I’d love to understand why these are important to you

Looks like that’s just an alias for the else keyword. I can log an issue to support this in Delphi Compatibility mode (but if PFC supports else too, why not just move to that? That can almost be done by bulk search/replace?)

28

We can do that (make it an official / permanent option).

3 Likes
29

Carlo:

can you log a docs issue for me what features exactly this option limits? I assume obviously any advanced {$IF syntax such as {$IF EXISTS. What about independent use of if defined() in code, would that still be valid, our not allowed? Id we make this an official option, we’ll need to doc the exact limitations.

I’ll make the option public in the IDE for vNext.

30

Thanks, logged as bugs://81606 — for docs on Legacy Preprocessor

31

Thanks, logged as bugs://81607 — for otherwise

33

bugs://81607 got closed with status fixed.

34

Thanks, logged as bugs://81796

35

bugs://81796 got closed with status fixed.

1 Like