type casting for switch/case?

[lupuss]

The following code of a field should beep if one clicks line 3 of the field

on mouseup
put (char 6 of the clickline) into linenum
switch linenum
case 3
beep
end switch
end mouseup

...but it doesn't. Only after performing an arithmetic operation with the variable linenum does the code work as expected:
put linenum*2/2 into x
switch x
case 3
beep
end switch

It seems to me that a type conversion has to take place before the switch statement functions properly.

[dunbarx]

Hi.

This works for me, and it reads correctly. Something else you are doing? What does lineNum have in it if you step through the code?

Just a thought, it would be more robust if you looked for word 2 of the clickLine instead of char 6.

Post back with what you find...

Craig Newman

[lupuss]

sorry, I simplified my code a little too much, since the original is very long. It shows the described behavior if linenum ist declared as (since I actually have more than 9 lines)
on mouseup
put (char 6 of the clickline & char 7 of the clickline) into linenum
switch linenum
case 3
beep
end switch
end mouseup

[Klaus]

Hi lupuss,

why don't you script "... word 2 of the clickline.." as Craig suggested (to avoid possible type conversion)?
That will work, believe us


Best from germany

Klaus

[lupuss]

why don't you script "... word 2 of the clickline.." as Craig suggested (to avoid possible type conversion)?
That will work, believe us

Yes, it works and it is more elegant anyway. I am just wondering if there is some provision for type casting in LiveCode (I have not found any commands) and if not ever specifying the type is really foolproof throughout the language.

[dunbarx]

But why did you grab char 6 AND char 7? To accommodate a possible two digit line number? Well and good, except that with a single digit line number, you now have a digit AND a space in your variable.

So when you test for the case "3", it fails, because the variable contains ("3" & space). This is not the same as "3" at all; it is a different string entirely.

And that is why doing some arithmetic helps, because when you add 0 to ("3" & space), you get a "3". But this is a machination that should be dealt with more robustly.

Robust is the catchword. Using the second word takes this concern out of the equation. It even accounts for seven digit line numbers.

Craig Newman

[lupuss]

But why did you grab char 6 AND char 7? To accommodate a possible two digit line number?

Well and good, except that with a single digit line number, you now have a digit AND a space in your variable.

So when you test for the case "3", it fails, because the variable contains ("3" & space). This is not the same as "3" at all; it is a different string entirely.

And that is why doing some arithmetic helps, because when you add 0 to ("3" & space), you get a "3". But this is a machination that should be dealt with more robustly.

Robust is the catchword. Using the second word takes this concern out of the equation. It even accounts for seven digit line numbers.

Craig Newman

I did intend to catch 2 digit numbers. That' why I used char 6 and 7. But if the language ignores type cast, I assume it should do an internal conversion, which also means that it should internally convert the blank to 0. In Lingo, for example I can ignore the type and write a="3" followed by put a/2 and have the result 1.5. But just in case there is the possibility to write value(a). I could sleep better If there were such an expression in LiveCode.
Apart from all that, using word 2 of the line is much cleverer as you already pointed out.

RoWo

[dunbarx]

OK.

But the main thing to learn is that the case structure is testing for the string "3", and you gave it ("3" & space). Since no arithmetic was involved, the strings stand as they are. The two strings are different.

LC is pretty forgiving when arithmetic does come into play: 3 + ("3" & space) does give you a 6. I think LC should remain strict when dealing with strings, as these are usually explicit data containers, and spaces, like anything else, matter.

Craig Newman

[lupuss]

OK.

But the main thing to learn is that the case structure is testing for the string "3", and you gave it ("3" & space). Since no arithmetic was involved, the strings stand as they are. The two strings are different.
Craig Newman

well, then - vice versa -

put "3" into a
switch a
case "3 " #(3 followed by a blank)
beep
end switch

should not beep, if blanks matter - but it does. Same for put "3 " into a and case " 3". On the other hand if a is "3 ", it matches neither with "3" nor with 3

To me, that situation is pretty confusing.

RoWo

[mwieder]

Code: Select all

put "3" into a
switch a
  case "3 " #(3 followed by a blank)
    put "yeah"
    break
  default
    put "nope"
    break
end switch

I get "nope", the way I'd expect. Something else going on there?

[dunbarx]

RoWo.

Mine does not beep. Odd that this is so for you. I wrote, in a button script:

on mouseup
put "3" & space into temp
switch temp
case 3
beep
end switch
end mouseup

No beeps.

If I put just a "3", I get a beep. If, in the original, I change the case to:

case 3 & space

I get a beep.

[lupuss]

Thank you both for the reply. After restarting my test it works as you indicated. When I last did the experiments, I now remember that I had some other stacks open which must have given me those inexplicable beeps. Now I've learned that I better use written output than beeps. Sorry for the turmoil, now I can rest in peace and thanks again for your patience!
RoWo