Good afternoon all,

Please after write the above procedure, I received the errors: Upper bound of case range is less than lower bound and duplicate case label

procedure DisplayGrade(Sender: TObject);
var
   grade    : String;
   tuitionFee: String;
   gradeSelected: String;
begin
    gradeSelected := cbbGradeList.Items[cbbGradeList.ItemIndex];
    case gradeSelected of
         '12'..'12': tuitionFee := '14500.00';
         '8'..'11' : tuitionFee := '13500.00';
         '1'..'7'  : tuitionFee := '8000.00';
    else
         tuitionFee := '850.00';
    end;
end;

^ ^ This should be easy to spot...

Regards,
Sven

Maybe changing the message to "lower or equal" would help?

Mattias

No, the error is in the line below.

> '8'..'11' : tuitionFee := '13500.00';

Note that strings are not numbers, so '8' > '11'.
Also, '1' < '11' < '7' < '8', so case branch labels intersect, which is the reason for the second error.

Mattias Gaertner wrote

Maybe changing the message to "lower or equal" would help?

No, equal values are acceptable, although useless.

Eric: "case of string" is not suitable for your task, use the usual "case of integer" instead.

I don't understand this error of lower bound and duplicate case label

Eric Kom wrote

I don't understand this error of lower bound and duplicate case label

Please see my previous response for an explanation.

Right... I forgot that this is a case of string -.-

Regards,
Sven

Should case of string really allow ranges?

THAT is an interesting question.

Regards,
Sven

Sven Barth wrote

> Should case of string really allow ranges? THAT is an interesting question.

I think it should not.
Ranges for strings are (countably) infinite, and this is (by design) not the case in the case of other cases (pun intended).

Bart

The lower-than and greater-than operators are defined for strings. Do you want to remove them too?

Ranges for strings are (countably) infinite, and this is (by design) not the case in the case of other cases (pun intended).

Mattias

I can see that somebody thought is was a good idea, by analogy with (if not direct equivalence to) cardinals. But shouldn't embedded strings be subject to internationalisation? And what happens when

'Apples'..'Oranges': begin
                      end;

gets translated to French? :-)

I've actually wondered about it a few times ;-)
You have a point - and I don't feel strongly about either way -, but in perspective AFAIR I've never needed - nor have seem a piece of code which did - more than one greater or less than comparison on strings in the same condition, so I'd say it's an unusual notion/construction.

-Fl?vio

Sorry, I'm late coming into this conversation and I may not be understanding the question/answer. But if I am, then case sensitivity should be part of any sort/comparison, at least as an option. I have had many problems when it is not. aA-Bb-Cc-dD is a form of randomness. If the result of a sort can not be reliably reproduced after adding new data, the sort fails. Case sensitive sort is common. Take a look at almost any spreadsheet program and you will see that it is an option. It's also an option in TStringList. In my opinion Case Sensitive should be the default behavior of any Sort/Comparison.

A case statement IMO should not rely on sort/compare options, unless there exists a syntax extension for such specifications. It also should be insensitive to string encodings (codepages).

If you want to be sure of the results, you replace the case statement by a chain of explicit comparisons, using the desired string comparison functions.

DoDi

No, you are missing the analogy I meant (or I did not make myself clear enough).

Case was originally meant for Ordinal values.
With Ordinal values ranges (1..100, 'a'..'z') are never infinite. Pascal has never had the concept of ranges (in this sense) that are infinite (countable or uncoutable).
You cannot define ranges for Floats (they would be uncoutable infinite), and by that analogy I would suggest you should not be able to define ranges for strings, as they are (coutbale) infinite.

The ability to have an infinite (countable or uncoutable) "range" between two values for a given type however, does not mean you should not have lesser than, or greater than operators. If this were the case we'ld have to remove them for floats as well, and that would be rather silly.

So my analogy was more with floats (but they have uncoutable infinite ranges, as opposed to coutable infinity for strings).

Bart

To implement a case LowerBound..UpperBound you only need a transitive compare operator. You don't need fixed size ranges. If you have small fixed size range then you can implement the case via jump tables. But that is only an implementation detail.

IMHO if you think that the string compare operator makes sense, then
strings in case makes sense too. They make exactly the same sense.

Mattias

it works! after I have removed the single quote and converted gradeSelected from string to integer.

Thanks for your contributions.

Bart wrote

You cannot define ranges for Floats (they would be uncoutable infinite)

Huh? Actually, you can. Real number interval is a well-known mathematical concept (see
http://en.wikipedia.org/wiki/Interval_%28mathematics%29), so I would actually suggest that they should be added to "case" operator too. Also note that, contrarty to "true" real numbers, floats are a finite set.

I did hope the context made it clear I meant range as in Ordinal.

Also note that, contrarty to "true" real numbers, floats are a finite set.

Of course.
Also, Strings (as defined in Pascal currently) are also not infinite, due to length limitation.

So, my argument was meant as some sort of philosophical perspective. I really don't care wether fpc implements it or not.

In the manner used by OP I would never use it, since it makes the code more diffcult to understand (just because of the ranges and the way < and > act on strings).
IMO Case should be used to make code more understandable.

Bart