RemObjects.Elements.RTL.Delphi: String = public DelphiString

I am trying to migrate an older project from Elements 2409 to 2595. The project uses RemObjects.Elements.RTL.Delphi. While it was working correctly under 2409, the code under 2595 appears totally broken. This includes messages such as

I believe the main cause of the havoc is the declaration in RemObjects.Elements.RTL.Delphi, which appeared since Elements 2409:

  String = public DelphiString;

This created a mess of String types in my project. My attempts to handle the problem all failed.

Thus, my question: How to properly neutralize the public String declaration in RemObjects.Elements.RTL.Delphi? This String type should not be visible outside RemObjects.Elements.RTL.Delphi.

Hmm. is this with EBuild being run form the command line, or from VS/Water? This is an uncaught exception, but I’ve never seen EBuild bubble one up as a dialog, as they should all be caught. can you run ebuild from the command line on your project with `–debug" and send me the full output, or better yet, can I see your project?

I believe thats always been there. The whole/primary reason of using Delphi RTL is that you want String to to behave like Delphi’s strings.

You don’t; if you use Delphi RTL, you’ll be using the Delphi string type, I’m afraid.

That said, I dont believe this is the cause of the above error.

VS 2019. Right now I do not see any point in debugging EBuild, because the code is really seriously broken.

Nope, twice. I have a DelphiRTL Source with folder date June 2020 (thus the code can be older) where there is no such declaration. The comparison in VS 2019 editor also clearly shows that with 2409 my own strings refer to RemObjects.Elements.RTL.String and in 2595 to RemObjects.Elements.RTL.Delphi.String. Definitely a difference.

Second, my reason for using Delphi is to have access to TStringList and some other Delphi T* types (which are needed by some older units), but otherwise I prefer using RTL strings.

In this case, I will need your assistance to recompile DelphiRTL without the public String declaration.

I do, because no matter how broken or wrong your code is, this should never happen, so I would like to fund out what causes this while we can (ie before we fox your code ;).

Okay, I cant be sure, because 2509 has been a long time ago. In either case, the current behavior as as designed and what we created Delphi RTL and DelphiString for.

One option would be to refer to these types by full names, rather than importing the namespace. It’s the “uses RemObjects.Elements.RTL.Delphi” that makes DelphiString the active string type. I’ll bring this up with he team to see if we can find any hacks to enable a scenario for you where you can get the types but not the alias, maybe via a different namespace. But I can’t make any promises.

You should just be ab le to open the project and compile it; that said, much of Delphi RTL itself depends on DelphiString, so I’m not sure how feasible that is…

OK then. This is the --rebuild --debug log, zipped: (2.8 KB)

The last console message, not recorded in log, was: “Process is terminated due to StackOverflowException.”

Thanx. a Stack Overflow explains the crash dialog. Can we get this project (via PM)? a SO is by definition a (bad) compiler bug, no matter how wring the code is…

Sorry, I can’t share the project, but I might try to minimize it to locate the problem. However, the strange thing is that I cannot reproduce the stack overflow on my home computer (the previous example was from my work comp). All the EBuild messages are the same, but no overflow at the end. This is very strange, because I remember getting exceptions yesterday also on my home comp. It is also curious because both VS and RemObjects were installed just a few days ago from exactly the same files.

Due to covid restrictions, I won’t be going to my work office for about one week, so please be patient expecting my test case.

Strange, exact same compiler version? different version of .NET maybe?

That’d be appreciated, as otherwise there’s very little actionable on this for us.

No worries, stay safe!

Bisection led me here, please check: (2.9 KB)


My college tells me he fixed a stack overflow yesterday; which might air might not have been the same issue; that fix should be in .2601; I’d appreciate of you could see if your issue persists with that one. I’ll also check tour testcase, now.


My test applies to 2595 and java. Under .net everything works fine.

1 Like

Nope, your test case still crashes here, with latest, so it looks like its a different bug from what was fixed. logging now…

Thanks, logged as bugs://85519

BTW, I tried to recompile RTL.Delphi without the notorious String = public DelphiString declaration. I was surprised to get a bunch of compiler errors, which I didn’t know how fix without changing the code. The majority of problems were occurring around several class Create… methods of DelphiString. I had to replace them with real constructors. I suspect I didn’t have the right Delphi compatibility setup.

But now it works and I am happy :slight_smile:

Did you build the project we provide, or add the source files to a new project? IIRC Delphi RTL does not use/need Delphi Compatibility Mode itself, internally.

Cool. :raised_hands:t3:

bugs://85519 got closed with status fixed.