Are "special" (like ñ, or accented vocals) character allowed in RODL? rodl2code produces correct files, Service Builder no

Remoting SDK
1

Hello,

I have a structure that has a field AñoFacturaGlobal. If we regenerate the _Intf using rodl2code then the files are correctly generated. If we do that from Service Builder then we get A_oFacturaGlobal instead.

I though it might be something related to encoding, but the files generated by Service Builder are UTF8-BOM encoded so at least it’s not on the “final step” of the recording that the character was mangled.

This is with version 1627.

2

That sounds like a SB bug. but i’m surprised, SB should be using the sam ecode adn rodl2code,. under to hood… Mayber a file encding or saving issue…

3

Logged as bugs://D19698.

4

Thanks Marc!

5

Hi,

what codegen (Apple Swift, C++ Builder, etc) are you using and what your system locale?

6

Hello Evgeny,

I’m producing BCB files. My system locale should be Spanish - México. I can confirm it later but that’s what it should be.

I haven’t tried generating either .net or Swift Interfaces for this RODL yet.

Rodrigo Gómez

7

We should really migrate all to UTF-8. iIt’s not 1984 anymore, and"what is your system locale" should not be a question anyone shoudl ever have t think about…

8

this limitation comes from Delphi 7 which is still supported:

{401C0451-B53B-4962-841D-7D7135AB1848}
{401C0451-B53B-4962-841D-7D7135AB1848}1231×646 61.2 KB

9

For a ahy platform, i’d be up to the user to not use invalid characters. Just as when they type code.

12

bugs://D19698 was closed as fixed.

13

Hi,

pay attention that ServiceBuilder is Delphi 7 application so don’t expect from it more …
However Delphi IDE can generate AñoFacturaGlobal w/o any issues:

14

So, only ServiceBuilder generates the invalid char?

We know rodl2code works fine, but I haven’t tried with the IDE. We rarely use that option. We can work with the rodl2code, although it would be better to have the same output from all the possible code generation paths.

Thanks

15

Hi,

I’ve removed limitation for using only latin chars and numbers (i.e.A-Z, a-z, 0-9 and _) as idents.

ServiceBuilder is Delphi 7 (i.e. non-unicode) application and it uses string ( = AnsiString) for storing idents. as a result, if your non-unicode locale supports accented vocals, SB will support it too.

for example, my non-unicode locale doesn’t support ñ so SB will generate AñoFacturaGlobal as AnoFacturaGlobal instead of A_oFacturaGlobal.