Weird Problem with a Switch Block

[Zohar]

Wow, quite a rich discussion this generated

OK, in any case I took Chimp's solution

and managed to solve it.

 

If Switch blocks should not support ranges defined by chars, like "a" to "z", then I suggest maybe making it not compile..

So people will not try it, and hence will not waste time on trying to figure out what is wrong..

[jchd]

binhnx,

I didn't see you edited your post in #13. Yet what you say there is wrong:

 

But for one-character-string, AutoIt normalize it to a ansi character. Then ™ becomes t (and ℣ becomes v, ℤ becomes z, but Ω cannot be normalized to ansi.)

Unicode ™ (codepoint 0x2122) does not become t in any case. What a conversion (normalization is a different beast) to ANSI yields depends on the ANSI codepage you're using. If your ANSI codepage actually contains the ™ character (e.g. the "western" Windows codepage) then its ASC('™') is returned (0x99 for western Windows) but if your codepage doesn't contain ™ then the conversion gives ? i.e. a question mark.

Any Unicode character which doesn't have its exact counterpart in the ANSI codepage you're currently using will convert to ? That's true for Ω and ℣ as well of course.

 

Zohar,

This isn't the correct way to handle the situation. Switch is clearly designed to handle strings in conditions and works correctly in all simple cases. Only when several compound condition using strings ranges appear does it go astray. This is definitely a bug and must be raised on Trac and acted upon by Devs.

Edited December 22, 2014 by jchd

[Gianni]

<....>

 

Chimp,

You and SmOke_N seem to regard Switch as something magical or esoterical but it's not so, even if it is currently buggy in some Case(s) [pun intended].

Your example is no different than:

Local $sMsg = "orange"

Switch $sMsg
    Case "apple" To "banana"
        $sMsgx = "It's a fruit"
    Case "table" To "bed"
        $sMsgx = "It's a furniture"
    Case "Tricycle" To "Car"
        $sMsg = "It's a vehicle"
    Case Else
        $sMsgx = "What's that?"
EndSwitch
MsgBox(0, $sMsg, $sMsgx)

If "apple" <= $sMsg And $sMsg <= "banana" Then
        $sMsgx = "It's a fruit"
ElseIf "table" <= $sMsg And $sMsg <= "bed" Then
        $sMsgx = "It's a furniture"
ElseIf "Tricycle" <= $sMsg And $sMsg <= "Car" Then
        $sMsg = "It's a vehicle"
Else
        $sMsgx = "What's that?"
EndIf
MsgBox(0, $sMsg, $sMsgx)

Strings are compared lexicographically over case-insensitive UTF-2 character set. How is that difficult to understand?

Conditions where <begin> is greater than <end> in a range are simply ignored, irrelevant of datatype(s).

Only the implementation --possibly using a buggy jump table or something fancy but wrong-- differs from a sequence of tests.

Change "banana" into "zebra" and see by yourself that is works fine, neglecting the fact that a zebra is not a fruit.

<....>

 

ok,  ... I see ..... "lexicographically"    is what I was missing, (a sort of alphabetically ordered)

so if we lexicographically (nearly alphabetically) sort the 3 strings: SearchedString <value1> and <value2>

and SearchedString falls in between or is equal to <value1> or <value2> then it match

thanks for the explanation.