Hi,

I have the following snippet of &#106avascript code which is acting in a rather odd way

var firstNewLine = content.indexOf('\n');if(firstNewLine == -1){   return {description : content};}    var typeString = content.substring(0, firstNewLine);typeString = typeString.toLowerCase()//other stuffif(imageDict[typeString] == undefined){  //other stuff}

In a particular run typeString ends up getting set to "bar" when I then index imageDict using this I get undefined. This is odd as when using the Chrome debugger if I place a breakpoint on the second if statement it shows that imageDict does indeed have a defined entry for "bar". If I put imageDict["bar"] into the watch expressions then I get the result I expect (A path to an image file) however if I add a watch expression for imageDict[typeString] I get undefined. So when the code actually runs the expression in the second if statement evaluates to true.

So it appears I have two strings "bar" and "bar" which are visually identical in their representation in the chrome debugger but &#106avascript considers different. Can anyone shed any light &#111;n what might be happening?<br><br>Note that this code works fine in other instances, it's just this &#111;ne particular case.

Is the length of each of your "bar" values the same? Could it be that the watch is not displaying some character, like a line feed or carriage return?

Quote:Original post by Konfusius...checking for undefined goes like this:

if(typeof imageDict[typeString] === 'undefined')

...

Imho the best way to check against undefined in &#106avascript is to declare an undefined variable in your current scope and check against that.

var undefined; // declare a variable called undefined and ommit the assignment...if (xyz === undefined) // now check against that variable, which in turn is undefined...

Turns out it was an extra '\r' character, something I really should have been able to work out on my own [grin], thanks smr.

Konfusius: Thanks for the tips, out of interest why do you think the typeof method is better than my current method of checking for undefined (Ignoring for now that I should be using the in operator for this anyway)? Is it because undefined isn't actually a keyword but &#106avascript interprets it as a variable that I haven't defined and thus has the type undefined so appears to act like an 'undefined' keyword would in this instance should it exist?

Quote:Original post by Monder...Konfusius:...Is it because undefined isn't actually a keyword but &#106avascript interprets it as a variable that I haven't defined and thus has the type undefined so appears to act like an 'undefined' keyword would in this instance should it exist?...

I'm not Konfusius, but let me answer instead ;-)

You're right, undefined isn't a keyword in &#106avascript. It is a global property to which no value (or to be correct: the value undefined) was assigned. That's why it is undefined. And that's why you can redeclare it in your local scope (like i did in my example above) or even assign another value to it.<br><br>But for Firefox 4 and above the global property undefined is read &#111;nly and cannot be redefined anymore:<br><a href="https://developer.mozilla.org/en/&#106avascript/Reference/Global_Objects/undefined">undefined at Mozilla developer center</a><br><br>With the use of typeof you need a string comparison, so using the equality operator === with an undefined property should give you better performance when doing lot's of undefined checks in a loop.

If you ever have the time, I recommend you to watch

">this video.
About fifteen minutes in there's some stuff about 'undefined'.