2008-10-30 5 views
10

У меня проблема в некотором JavaScript, который я пишу, где оператор Switch не работает должным образом.Заявление об отключении JavaScript

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; 
} 

ResultType - целочисленное значение 0-2, и я вижу это в FireBug. Во всех случаях коммутатор передает управление команде окончательного разрыва, что означает, что вся логика полностью пропущена. Что мне не хватает?

ответ

19

Я уверен, что коммутатор использует === для сравнения в Actionscript и так как JS и AS и следовать стандарту ECMAScript, я думаю, то же самое относится и к JS. Я предполагаю, что это значение не является числом, а, возможно, строкой.

Вы можете попытаться использовать parseInt (msg.ResultType) в коммутаторе или использовать строки в случаях.

+8

ВСЕГДА укажите второй параметр parseInt! Это радикс, поэтому вы, вероятно, захотите: parseInt (msg.ResultType, 10); Если вы не поставите его, он попытается угадать, что произойдет, и произойдут ужасные вещи. – rmeador 2008-10-30 14:12:29

+0

Ну, ужасные вещи произойдут, если вы передадите что-то вроде 077, которое будет интерпретироваться как восьмеричное (но не 078, например), или 0x10, но во втором случае довольно ясно, что у вас есть база 16. В любом случае добавление radix явно не повредит, так что это тоже неплохая идея. – 2008-10-30 14:25:45

2

У меня возникла аналогичная проблема, и проблема оказалась такой, что, когда она показывалась как значение int, оператор switch читал ее как строковую переменную. Может быть, здесь не так, но вот что со мной произошло.

0

Вы уверены, что ResultType является целым числом (например, 0), а не строкой (например, «0»)?

Это легко может объяснить разницу в поведении

+0

Это было определенно целое число в соответствии с FireBug. Не то, чтобы это окончательный источник, но довольно хороший показатель. – 2008-10-30 14:09:06

0

Похоже, что смена его на parseInt (msg.ResultType) заставила механизм JavaScript правильно рассматривать его как целое. Спасибо за помощь.

2

Попробуйте это:

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; 
} 

-0 заставит (принуждать) его лечение вашего значения как целое число без изменения значения, и это гораздо короче, чем ParseInt.

0

Первое, что я заметил, это то, что в двух из трех случаев вы вызываете .val(), а в третьем вы вызываете .text().

Если вы попытались изменить операторы case на строки вместо ints, то единственное, что я могу придумать, это то, что вы удаляете исключение где-то вдоль линии, возможно, вызванное доступом к неопределенной переменной.

0

Вероятно, самым мощным понуждение к Int доступны в ES5 является:

 msg.ResultType | 0 

Это один из краеугольных камней, на которых asm.js проживает. Это приводит к самого оптимизированной ES5 и используется при компиляции на наличие:

"use asm" 

директивы (в FF и хром). Это принуждение приводит к тому, что тип Int32 используется для чисел в ES5, которые представляют собой «int». Таким образом, рецепт рецепта поваренной книги по оригинальному вопросу от 5 лет назад:

"use strict" ; 
$("#txtConsole").val(
    switch (msg.ResultType | 0) { 
    case 0: 
      "Some Val 0"; 
    break; 
    case 1: 
     "Some Val 1"; 
    break; 
    case 2: 
     "Some Val 2"; 
    break; 
    default : 
     "Illegal ResultType"; 
    });