Oxygene/C# mixed code

Thanks, now i understand your engine approach, which doesnt count C# method declaration as a declaration for pascal and causes other processing failures. That is strange to me, but undrestood.

The main problem for me (which im trying to achieve a solution here) are these two errors:

  • ClassA.pas(19,12): error E633: Cannot invoke type “ClassA”, did you mean to use new?
  • ClassA.pas(20,5): error E513: Parenthesis are required to call method Apply()

The Purpose of our code is: we are trying to split method implementations we have now all in pascal to two ways

  1. pascal (if need be)
  2. c# (new implementations)
    Within same assebly, under one declaration (ideal in C# )

Im trying to get to know, how far can we go on mixing pascal and C# while minimizing pascal. No hard feelings. Now i know, we have to generate pascal declaration for pascal methods and the C# declarations are useless for this case.

Is it going to be a build relese with global using bugfixes today ? Thanks.

But these are follow-up errors of the missing declaration. iof you fix that, they go away. (I also believe .2841 will have a fix for these).

In a single class, you cannot “split” a single method between toe files (or languages), no. Whats the actual goal you are trying to achieve here?

.2841 today will have the fixes fo the above, yes.

I dont need to split the method, that is absurd. I wanted to declare it in C# partial class and implement in Pascal partial class. That is in the testcase.

.2841 is still not available…

Well. you say po-tay-toe, I sayb po-taa-toe. That’s what “splitting” it means. C# doe not have a concept of separate method declaration and implementation. you cannot “declare” a method in C# without implementing it. And you can’t implement a method in Oxygene if its not declared in the same file. This is as designed.

I still don’t understand what concrete problem you are trying to solve, though…

—marc

Yes, I’m aware. We had an (unrelated) showstopper that prevented us from shipping a build last Friday. 2841 will be out this coming Friday; i can send you an interim build of you need?

Up in Personal Downloads, now.

Thanks, just checked and global using itslefs looks good, but the preprocessor ignores directives inside the section with global using, is that intensional ?

image

Please see, the attached solution and a compile error in project GlobalUsingsTC.elements

ElementsTC.zip (48.3 KB)

Thanks.

Well. “true” isnt defined so technically this is correct. That said, unknown namespaces seem to err in both parts, so that is indeed a big. logging that one.

Logged as bugs://E26599.

Well, If true is not defined, then there is another bug, it behaves like it was.
There


is the true block active in the IDE and code compiles like this:

Hmm, curious. I’ll check with the team; I don’t believe it should be like that… might be a corner-case

bugs://E26599 was closed as fixed.

Hello, ive just found a similar bug as E26599 with global using static syntax in version 10.0.0.2845. Static using is validated even in the conditional inactive code.
There is a project with a testcase:
GlobalUsings.zip (1.8 KB)

Just try to build it (in Visual Studio or MSBUILD) , there are two errors, but only one is legit.

(cíl CoreCompile) →
C:\Users\tumal\Downloads\GlobalUsingStatic\GlobalUsings.cs(3,21,3,39): error E28: Unknown type “UnknownStaticUsing” [
C:\Users\tumal\Downloads\GlobalUsingStatic\GlobalUsingsTC.elements]
C:\Users\tumal\Downloads\GlobalUsingStatic\GlobalUsings.cs(5,21,5,39): error E28: Unknown type “UnknownStaticUsing” [
C:\Users\tumal\Downloads\GlobalUsingStatic\GlobalUsingsTC.elements]

weird, isn’t that the same scenario that was supposed to have been fixed? checking…

bugs://E26599 was reopened.

bugs://E26599 was closed as fixed.

Yes, that works frorm ne now in 11.0.0.2851.
Sadly, a have another report:
Global type aliases declared in C# code are not visible from Oxygene code and compiler throws: (E28) Unknown type "GlobalTypeAliasFor" GlobalTypeAliasTC)

The global using declared in C# work also for the Oxygene and thats why i think, the alias should work as well.
We are pushnig it to the limits, we know that.

There is an example solution:
TC.zip (3.3 KB)

Thanks for considering.

Logged as bugs://E26628.

Hrmm… I’m getting:

Build started...
1>------ Build started: Project: TypeLibrary, Configuration: Debug Any CPU ------
2>------ Build started: Project: GlobalUsingsTC, Configuration: Debug ------
2>		GlobalUsingsTC -> C:\Users\carlokok\Downloads\TC\GlobalUsingsTC\bin\Debug\GlobalUsingsTC.dll
1>TypeLibrary -> C:\Users\carlokok\Downloads\TC\TypeLibrary\bin\Debug\net48\TypeLibrary.dll
========== Build: 2 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Elapsed 00:12,018 ==========

Hmm, is it with 2851 build ? Maybe an installation issue ? All of our test-machines fails same way.

By the way, one of our developers did some C# syntax test and found some differences to the Rosyln C parser, you might be interested in.
See the example solution here:
TestProject.zip (6.1 KB)
There are 5 cases which do not work with Elements, but do work in standard C#.
Sixth case is false-positive identation warning. The file is formatted with Visual Studio 2022 with default formatting.