UTF8 Problems

[JD]

Hi there everyone,

I have a problem with a case statement in an old project. {$codepage UTF8} was set near the beginning of the file. When I compile it, I get the error shown below

Code: Pascal  [Select][+][-]

1. unit1.pas(38,34) Error: Constant and CASE types do not match
2. unit1.pas(38,34) Error: String expression expected
3.  

The line with the error is shown in the attached screenshot. Does anyone know how I can fix this problem?

Thanks,

JD

[wp]

Remove the directive {$codepage utf8}. It helped when I simulated your issue although I don't understand (Lazarus source files are utf8 anyway, aren't they?)

[Thaddy]

case <string> is a bug feature of FPC and is strictly ANSI afaik. It isn't supposed to work with UTF8, because there IS no UTF8 support in the compiler itself.

[wp]

But why is the case statement working if the {$codepage utf8} is removed? If I open the file in NotePad++ it tells me that the file is UTF8. So, the compiler is able to understand UTF8.

All this is very confusing, and I have always tried to avoid additional directives and "exotic" string types such as rawbytestring or the codepage aware strings declared at compile time etc. Using plain-old "string" without any directives works in 95%, probably even more, of all programs that I write.

[Thaddy]

No, the compiler listens to the codepage of the underlying OS. Which is probably CP863. Therefor it works. Up to a point. Like for French. But not for all languages.
The same code will probably fail on other platforms than Windows. Unless the strings hash the same.

[marcov]

So in addition to Thaddy, to state the obvious:

the compiler is compiled with ansistring(0), so on windows that means the default windows codepage (ansi codepages like windows-125x, not OEM codepages like cp852 like Thaddy says, though they are mostly 1:1 matched)

So anything inside the compiler that doesn't have special treatment (like literals) will use that codepage.

Literals have a special pass through to allow literals in varying codepages to be transfered to the final binary.

The choice for one-byte unicode/utf8 strings on Windows was doomed from the start, and should have been avoided, for exactly these reasons.

[Thaddy]

All these string types, indeed.
cp is probably 1252-1.

Maybe a documentation issue in FPC.

Then again, people should use case of <string> with care. I wish someone put that genie back in its bottle.

[JD]

All these string types, indeed.
cp is probably 1252-1.

Maybe a documentation issue in FPC.

Then again, people should use case of <string> with care. I wish someone put that genie back in its bottle.

Thanks a lot Thaddy. I replaced the case statement with an if statement & I was able to proceed. Now I will do the same with all the other case statements in the project.

The funny thing is that in another project, I had used case statements with case of <variant> and that worked. I might add that the variant was the mORMot TDocVariant type.

The other strange thing is this whole problem came to light with Lazarus 1.6.4/FPC 3.0.2. The last version Lazarus 1.6.2/FPC 3.0 did not complain at all.

Cheers,

JD

[JD]

Using IndexStr also works with {$codepage UTF8}

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. begin
3.   //
4.   case IndexStr(Edit1.Text, ['Sondages', 'Internet', 'Bouche à oreille', 'Partenaire']) of
5.     0 : ShowMessage('First option');
6.     1 : ShowMessage('Second option');
7.     2 : ShowMessage('Third option');
8.     3 : ShowMessage('Fourth option');
9.   end;
10. end;
11.  

NB: IndexStr  is in StrUtils.pas

JD