How to use DelphiRTL with an Oxygene project

I’m trying to port a Delphi project to .Net and as the Oxygene compiler looks promising, I setup a project in Visual Studio where I’m referencing one unit for a start.
As I expected, it does not compile “out of the box”, there are a few options to activate in project options.
However, the most common error is where it complains about unknown namespaces in the uses section, most notably for Delphi’s own RTL units.
As indicated on your “Escape from Delphi” page, there is a project at GitHub that aims at providing those missing units: https://github.com/remobjects/DelphiRTL

I have cloned that repository locally and have added the DelphiRTL.shared.elements project to my solution, but this did not help with the “uses” errors.

What did I miss?

My ultimate goal here is to avoid changing the original code as much as possible.

FWIW, we ship Delphi RTL pre-compiled with Elements, all you need to do is add a referencer to Delphi.dll (or, say, Delphi.fx, for Island) to your project. That said, a project reference to a local clone will of closer work too.

Oxygene doesn’t;t use per-unit names for there uses clause, but it uses namespaces. All the Delphi RTL types are in the RemObjects.Elements.RTL.Delphi namespace, so once you added a reference to the library, you can just replace the Delphi-specific per-file uses entries (such as SysUtils, etc) with RemObjects.Elements.RTL.Delphi and you should have access to all the types and global methods provided by the Delphi RTL library.

See Namespaces and References for a more detailed discussion on how references and namespaces work in Elements, from a Delphi user’s perspective and see Delphi RTL for list of compatibility APIs provided as part of Delphi RTL (and VCL).

Hello,
from my experience you can not avoid to make your code compatible with the Elements-Toolchain.

In my Units a uses clause looks like:

{$IFDEF ELEMENTS}
 uses
   RemObjects.Elements.RTL.Delphi;
{$ELSE}
  uses
    System.SysUtils,
    Generic.Collections;
{$ENDIF}

Fair enough, that’s what I started to realize.
If we’re moving ahead, it’s going to hurt, there are literally thousands of units in this project.
And apparently, there are other syntax differences. I have spotted the way generics are constrained (colon vs is), the fact that anonymous functions cannot have their own var section before the begin keyword, the From keyword is reserved…

Ah well, we’ll have to see what we can do here with all that.

Alternative would be to add RemObjects.Elements.RTL.Delphi; to the project’s default uses clause setting, and add a unit that defines all namespaces you wanna “ignore” as dummies, eg

type
  System.SysUtils.Foo = private Integer;
  Generic.Collections.Foo = private Integer;
  ...

that way, these names would all exist as namespaces, and can stay in the uses clause, albeit being useless (haha) there…

I believe that’s now supported in Delphi Compatibility Mode.

Oxygene has a myriad of new keywords, yes. You should be able to except those with & — afaik that’s supported in Delphi too, right?

I had already found the project setting, but I did not know about that strange idea you got there. It does work, that’s really strange to me, but it works.
Now, I have done it for my own project, but would there be any issues if it was done inside DelphiRTL itself?

Well, I have activated this mode but with this code:

TLightweightObjectList<T: class> = class(TLightweightList<T>)

it tells me “Greater than or comma expected, got colon”

As to the & prefix, you are definitely right, it works.

I guess we could do that,

Hmm. with the latest, .2467?

Well, the latest public build is 2461, which I am using right now. At least, that’s what the about box is telling me.

If you are using Water/Fire, you can go to the menu’s Tools > Options and in the General tab there is an option “Check for updates on channel:” which you can set to Preview instead of Stable. This should pull .2467 instead of .2461. I always use the preview and very rarely have issues with it.

1 Like

Can you try .2467? this was added fairly recently, and might have been post .2461’s release.

Well, I tried to do just that, and it did download a file called “RemObjects Elements with Water - 10.0.0.2467.exe”
However, that file is only 35 bytes long and when viewed with Notepad, it contains this text:

NOT AUTHORIZED (1)FalsePreviewFalse

I also went to the remobjects download page for my account, and only 2461 is accessible there. I can see 2467 in the “preview” section, but it is stricken out, so no dice here either.

Curious. is your license active? What account are you using?

I’m using the “trial” extension you sent me earlier, maybe this comes from that.
I tried going to the download page with both my personal (obones) and company account, but this gave the same result, access to beta version is not allowed.
But I don’t find this illogical, after all I’m on the trial.

What could be improved, though, is that the Water IDE checks for the resulting file to be a valid exe file rather than an error message.

Curious. Are you logged in with any account at all? the Preview channel should not report any download at all without login, rather than linking to a file you cant’ access. I’ll see what’s going on here and get that fixed. I’ll also url;oad today;'s upcoming .2469 build to your Personal folder (user “obones” ok?), when it’s done later today.

Indeed, but…

also indeed, Water shouldn’t even see the download, let alone download the “access denied” error message and treat it as an installer. I’ll see why that happens and get that fixed for next week’s update.

Thanks, logged as bugs://83735

Fixed, server side

Yes, I see that now, it does not try to download anything and tells me 2461 is the latest one.
As to sending 2469, yes, obones is fine

1 Like

Up now.

Yep, seen it, installed it.
Both VS and Water tell me it’s the version that I’m using. But both also tell me that he license I was using expired on December 19th.

I fired up the RemObjects.Everwood.LicenseManager.exe file and it tells me that the license is valid until January 16th:

image

Too much mystery here…

Ah well, off for the week-end then :wink: