I'm definitely doing something wrong

[Utherr12]

http://pastebin.com/1jLVqJbj <-- ChangedI input the number 14 and 14 fields are created. Ok, this works. Then afterwards if i input 15... another field is created with the name 141.... i tried 16 and it gave me 141 and 142. Why does it consider q_nr a string??The second else if doesn't work either. It just doesn't do anything. Input 14, then 10...and nothing happens.Later Edit: i changed the last else if like so:

for(i=CurrentOptions; i > nr_opt; i--)			$(document).ready(function(){				$('p:last').remove();				$('br:last').remove();			});

and it works wonders.I've updated the pastebin.

[[dx]]

Can you try:q_nr = eval(CurrentOptions + j); Couse CurrentOptions + j assign values one next to other like 'Hello'+'World' will result HelloWorld.And eval() function calculates it.

[jeffman]

var nr_opt = document.getElementsByName('no_options')[0].value;

The problem is that nr_opt is a string. When you compare it to a number value using the comparison operators (< == >), if nr_opt looks like a number, it will be evaluated as a number. (This is a feature, not a bug.) But when you add something to nr_opt with the + operator, the result might be a string also, as haris points out. That is because the + operator is overloaded in JavaScript. It performs different operations depending on the context. (Also a feature, not a bug -- but it can be confusing.)The easiest thing to do is to fix this at the source:

var nr_opt = Number(document.getElementsByName('no_options')[0].value);

Now, nr_opt and CurrentOptions should be numbers, and behave like numbers, throughout the entire script.FWIW, eval() is best avoided whenever possible.

[Utherr12]

Ok thanks guys, a lot.

FWIW, eval() is best avoided whenever possible.

Why is that? Is eval() deprecated?I have another qustion what does getElementById returns if the element doesn't exist? I tried null or "" and doesn't work :-s.LE: Oh it returns "undefined" .

[jeffman]

"deprecated" means the original designers have indicated you should not use it. eval has not been deprecated, and there are situations where it is the only thing that will work.Programmers do avoid it when they can because it is inefficient. It's whole job is to take a string and turn it into code. The process is much slower than it would be if the code existed as code in the first place. Using eval a few times in a program is pretty harmless. But if you get used to it, then eventually you might find yourself building it into a loop that iterates 1000's of times, and that could drastically affect the performance of your program.In the case Haris suggested, it's bad practice because the intent of the operation is not immediately clear, simply because eval can be used for a bunch of different things. The Number operation I showed you is unambiguous. Anyone trying to maintain your code (and this includes you six months from now) can look at it and know immediately what the intent of the operation is.

[jeffman]

On some browsers it might return as null. Better to check it against both.

[[dx]]

Where do you read about these userful tricks

[jeffman]

@HarisIf you are asking me, I probably do what most developers do. I read a lot. I have read something about every HTML element that exists, every built-in JavaScript function that exists, and so on. A thing that happens a lot, is I will search the Internet for information on one topic, and I will find a tutorial or bulletin board with useful information. But I will also notice that someone's example uses another technique that I wasn't looking for. I think, that will come in handy some time. I I remember it, or book mark the page, or copy/paste something into a document where I can find it later.I also study other developers' code. It's pretty easy to tell when code is so badly written that I can learn nothing from it. Better code usually has something I can learn from.Some things are true of all modern programming languages. In this case, most languages have a technique for casting the value of one variable type into a different type. They are all a little different. So when I learn a new language, one of the first things I learn is how the new language does type casting. I didn't wait to be shown. I knew it was something to look for, so I look for it.The same is true for operators and control structures. I automatically look for reference material that discusses them.Most languages also have procedures for concatenating strings, adding and removing items to/from arrays, and so on. I look for that stuff right away.You can learn a lot by waiting for problems to come up and then solving them. You can learn a lot more by experimenting just for fun. And you can learn a lot more by going out and looking for things.