I did do a search and couldn’t find anything, so my apologies if this has already been answered.
I’m having a little problem when I test a game within IE9.
Whenever I use the command *input_number
It throws up an error:
“Could not get the type property. Invalid argument.”
Whenever I remove that command it works just fine, so I imagine it’s something wrong with the interpreter (or more likely, Internet Explorer itself).
It’s actually not a huge deal, since input_text still works and I can use that instead, but I thought I’d see if anyone else has had the same problem and/or has a solution.
@CJW, did you ever figure out the problem with *input_number on IE9? Thing is, I can’t even get *input_text to work for me in IE9. I get the same error message you got with *input_number, and that’s even when I put the game on a web server.
I’m seeing other weirdness with IE9. I tried to use the base CS downloaded files for a test, and they work fine until I touch a scene file, even to just “Unblock” it in Windows Explorer, at which point IE9 refuses to load it, saying “Permission denied” in one case and “Invalid character” followed by “Unable to get value of the property ‘setStartingStatsClone’: object is null or undefined” in another. What’s up with that?
Okay, so I found out (here) that the problem with the downloaded base files in IE9 is that if you don’t Unblock the zip file before you extract the files, it can cause problems in IE9. Stupid compatibility mode seems to affect it too.
So *input_text is working for me after all, but *input_number is still a problem for me and gives the same error message you mentioned. Have you uncovered anything new on this problem?
I see the problem with the *input_number command. The implementation of the command in ui.js tries to assign the value “number” to the “type” of an HTML input element. Firefox and other browsers don’t allow the assignment, leaving the value of the “type” field as “text” instead of changing it to “number”, but they don’t throw an exception either. IE sees that an illegal value is being assigned to the “type” field of an HTML input element, and throws an exception.
The fix, therefore, is to not attempt the illegal assignment. I generally avoid modifying the CS core files, so what I did was to create a separate file, print_input.js, in which I placed the correct code, and then in the index.html file, I included this print_input.js file, making sure to include it after ui.js, so that the definition of the printInput function in ui.js is overwritten by the printInput function in the print_input.js file.
Here is code for the printInput function that will work. You can compare to the function as it is in ui.js to see the slight change.
function printInput(target, inputType, callback, minimum, maximum, step) {
if (!target) target = document.getElementById('text');
var form = document.createElement("form");
target.appendChild(form);
var self = this;
form.action="#";
var input = document.createElement("input");
if (inputType == "number") {
input.type = "text";
input.setAttribute("min", minimum);
input.setAttribute("max", maximum);
step = step || "any"
input.setAttribute("step", step);
} else {
input.type=inputType;
}
input.name="text";
input.setAttribute("style", "font-size: 25px; width: 90%;");
form.appendChild(input);
form.onsubmit = function(e) {
preventDefault(e);
if (!input.value) {
// TODO optional value?
// TODO configurable error message?
alert("Don't just leave it blank! Type something!");
return;
}
callback(input.value);
return false;
};
form.appendChild(document.createElement("br"));
form.appendChild(document.createElement("br"));
printButton("Next", form, true);
}
I actually side-stepped the issue by using javascript prompt boxes, but this works a lot better… Good job! We should really try and get these things stickied or something.
