Constructing a constant string

[MarkMLl]

Apologies if this is an FAQ, but "Free Pascal allows the use of strings as case labels, and in that case the case variable must also be a string.".

While working on something to diagnose rubbish coming from hardware I wrote

     case command of
          'A',
          'a': begin
...
          #$ff + #$00 + #$00 + #$ff + #$00 + #$00 + #$ff + #$00 + #$00: begin

which failed with a type error, while

    const a110=  #$ff + #$00 + #$00 + #$ff + #$00 + #$00 + #$ff + #$00 + #$00:;
...
     case command of
          'A',
          'a': begin
...
          a110:

 worked. How can one construct a string inline with the code which contains non-printing characters but is guaranteed to be evaluated at compilation time?

MarkMLl

[Handoko]

Yes, you're right. Your first example does not work, I just tested it on my Lazarus 2.0.4. But at least this below works:

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

1. procedure TForm1.Button1Click(Sender: TObject);
2. var
3.   a: string;
4. begin
5.   a := #$ff + #$00 + #$00 + #$ff + #$00 + #$00 + #$ff + #$00 + #$00;
6.   case a of
7.     'a': ;
8.     'b': ;
9.     #$ff#$00#$00#$ff#$00#$00#$ff#$00#$00: ShowMessage('This works!');
10.   end;
11. end;

Maybe an incomplete feature or bug?

[MarkMLl]

Thanks, I'd forgotten (or never knew about) that form. Should probably be documented in the "Constant strings" section of the manual.

In practical terms I'm probably going to change my code to not use that, but this was a case where separating the sequence of characters/bytes and the code that was reacting to them detracted a lot from clarity.

[winni]

Hi!

There is another feature (or bug?) about strings as case labels should be mentioned.

If you use a range of strings the labels are only treated as leading substrings.

Example:

// working on function keys

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

1. case idx of
2. 'F1'..'F9'    : .....
3. 'F10'..'F12' : ..... // <-- compiler error
4. end;
5.  

The compiler moans in the second line of case labels: "Error: duplicate case label"

This means that in the label 'F1' the labels 'F10'..'F12' are contained.

If you know that, it is useful for some reasons like working with dictionaries.

But in the above example you have to do

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

1. case idx of
2. 'F1', 'F2'..'F9'    : .....
3. 'F10'..'F12' : ..... // <-- no compiler error
4. end;
5.  

Here the F1 is not in a range but a single value and will not be expanded.

Btw: Good to  know is the strange policy from M$ about function keys F13..F24:

In Windows 7 (and Apple) pressing Shift F1..F12 leds to the result F13..F24

In Windows 8 F20..F24 are disabled

In Windows 10 F13..F24 are disabled

Happy coding
Winni

[winni]

@Thaddy

Despite the documentation: It works fine!

Never confuse theory with practice
Key lesson: never eat the menu card

And about strings as case labels: It is cool and I waited over 20 years for them!

Winni
     

[Thaddy]

You should report that ( in my hope string case labels go away ) because indeed a "duplicate case label" error is thrown and that is not according to the documentation.
It should not work "sometimes". Both your examples should work.

[PascalDragon]

Thanks, I'd forgotten (or never knew about) that form. Should probably be documented in the "Constant strings" section of the manual.

It is documented as part of the ordinary string syntax.

You should report that ( in my hope string case labels go away ) because indeed a "duplicate case label" error is thrown and that is not according to the documentation.
It should not work "sometimes". Both your examples should work.

I don't know if ranges for strings are even intended to work or if it was forgotten to correctly disable them for case-of-string...

[Thaddy]

I don't know if ranges for strings are even intended to work or if it was forgotten to correctly disable them for case-of-string...

Well, it is documented that ranges work, in some quirky way...
https://freepascal.org/docs-html/ref/refsu56.html

At the bottom.... ? Maybe that should be removed...
(btw: you made my day last week by fixing the class const thingy!)

[egsuh]

Followings are only my guess.

Case statement with strings are different from case statements with ordinal type ... they are just like nested  else if statements.  So the range does not act like with ordinal types. It seems to act just like  (if >= and <=). 

So, in the following case,  'F10' is larger then 'F1' and smaller than 'F9', which caused duplication. 

     case s of
        'F1'..'F9' : // do something;
        'F10'..'F12': // do something
     end;

But,  in the following case, there are no duplication.

     case s of
        'F1', 'F2'..'F9' : // do something;
        'F10'..'F12': // do something
     end;

'F1'..'F9' is not 'F1', 'F2', 'F2', ....

[lucamar]

Case statement with strings are different from case statements with ordinal type ... they are just like nested  else if statements.  So the range does not act like with ordinal types. It seems to act just like  (if >= and <=).

Yes, it's documented in the Reference Guide:

The case with strings is equivalent to a series of if then else statements, no optimizations are performed.

However, ranges are allowed, and are the equivalent of:

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

1. if (value>=beginrange) and (value<=endrange) then  
2.   begin  
3.   end;

[Thaddy]

That's why I wrote "Quirky".... Anyway that string case syntax still bothers me...

[PascalDragon]

Case statement with strings are different from case statements with ordinal type ... they are just like nested  else if statements.  So the range does not act like with ordinal types. It seems to act just like  (if >= and <=).

Yes, it's documented in the Reference Guide:

The case with strings is equivalent to a series of if then else statements, no optimizations are performed.

However, ranges are allowed, and are the equivalent of:

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

1. if (value>=beginrange) and (value<=endrange) then  
2.   begin  
3.   end;

Then the error indeed makes sense. Well, less work more me 

[MarkMLl]

If it makes sense, is it really an error? :-)