tags:

views:

1994

answers:

6

I have problem in some JavaScript that I am writing where the Switch statement does not seem to be working as expected.

switch (msg.ResultType) {
  case 0:
    $('#txtConsole').val("Some Val 0");
    break;
  case 1:
    $('#txtConsole').val("Some Val 1");
    break;
  case 2:
    $('#txtConsole').text("Some Val 2");
    break;
}

The ResultType is an integer value 0-2 and I can see that in FireBug. In all cases, the switch transfers control to the final break statement which means all the logic is completely skipped. What am I missing?

+2  A: 

I ran into a similar problem and the issue turned out to be that where as it was showing as an int value, the switch statement was reading it as a string variable. May not be the case here, but that is what happened to me.

Jeremy Reagan
A: 

Are you sure the ResultType is an integer (e.g. 0) and not a string (e.g. "0")?

This could easily explain the difference in behaviour

Gareth
It was definitely an integer according to FireBug. Not that it is the definitive source, but a pretty good indicator.
Joe Brinkman
+7  A: 

I'm sure that a switch uses === for comparison in Actionscript and since JS and AS both follow the ECMAScript standard, I guess the same applies to JS. My guess is that the value is not actually a Number, but perhaps a String.

You could try to use parseInt(msg.ResultType) in the switch or use strings in the cases.

Juan Pablo Califano
ALWAYS specify the second parameter to parseInt! It's the radix, so likely you'll want: parseInt(msg.ResultType, 10); If you don't supply it, it will try to guess the radix and horrible things will happen.
rmeador
Well, horrible things will only happen if you pass something like 077, which will be interpreted as octal (but no 078, for example), or 0x10, but in the second case it's rather clear that you have base 16. Anyway, adding the radix explicitly won't hurt, so it's not a bad idea either.
Juan Pablo Califano
In this case the radix is not necessary, although I have used it just for clarity and completeness. I am not someone who believes terse code is the best code. The values coming in are defined in an enumeration on the server side and so will never be in some non-standard format.
Joe Brinkman
078 will be interpreted as octal as well: parseInt("078") returns 7. parseInt("08") returns 0. These can be the source of nearly impossible to find bugs.
rmeador
Sorry for being misleading, I tested it only in AS, where parseInt seems to be implemented in a slightly different way than in JS (so parseInt("078") returns 78 ).
Juan Pablo Califano
A: 

It looks like changing it to parseInt(msg.ResultType) has forced the JavaScript engine to properly treat it as an integer. Thanks for the help.

Joe Brinkman
A: 

Try this:

switch (msg.ResultType-0) {
  case 0:
    $('#txtConsole').val("Some Val 0");
  break;
  case 1:
    $('#txtConsole').val("Some Val 1");
  break;
  case 2:
    $('#txtConsole').text("Some Val 2");
  break;
}

The -0 will force (coerce) it to treating your value as an integer without changing the value, and it's much shorter than parseInt.

Joel Coehoorn
This is one of those answers that is slick, but not as explanatory as using parseInt.
Aaron Palmer
And presumably, Javascript will just be calling parseInt behind the scenes, so all we are saving is a bit of typing.
James Curran
Tried this and it did not work. I still ended up with the original problem. The parseInt (with and without radix) worked reliably.
Joe Brinkman
A: 

First thing I noticed is that in two of the three cases, you're calling .val() and in the third you're calling .text().

If you tried changing the case statements to strings instead of ints, then the only thing I can think of is that you're hitting an exception somewhere along the line possibly caused by accessing an undefined variable.

17 of 26