Sorry, but I am picky

you stated ....in the case of "number"+1 it adds 1 to number.


I would state that as: in the case of "number"+1 it concatenates 1 to number, it does not "Add" the string number and the integer 1 as this can not be done.(;-)

I know what you mean and it was probably a typo, but there are many readers out there who would just scratch their heads.

Lyndel is also a JSLint fan. I will have to take a look at it. I use the Cpoint js editor.

Hehe, ok.

Well then I suppose it works because add in my language has two translations that are used in different context, one for numbers and one for not numbers. Where you have "add 3 to 5" and "add sugar to lemonade" we have 2 different words for add. So maybe it's beacuse of this that it works for me.

In any case you know what add means from the context in the cases above, this is why I do "" + 1, so In my defense :) -> I have a string I add something to it so it becomes a longer string ;).

Try JSLint (jslint.com), will spare your health. I red on the Prontoscript Library development guide that a script for Apache ant is available that does JSLint and yui compress at the same time, but haven't tried it yet.

But still I prefer the overloading of + than of || like it was mentioned here, because I really can't think that much out of the box to OR a string with a number. For me it's like "Divide by zero", must be my electronics background. :)

Everyone and BluPhenix,

I never claimed that "||" was the proper operator for this sort of operation in ProntoScript. (It may work for some contorted special case, but I can't think of one off hand) In another language this is exactly the operator to use. In my comment above I wanted to avoid using the confusing "+" syntax and concentrate on the process.

---
(elapsed time)

OK, I thought of an example. While it would make a wonderful homework assignment or a nasty exam question, I can't imagine why anyone would want to use the technique in a production JavaScript program. A very simple, straight forward line of code would turn into an entry for the obfuscated code contest.

buzz, hey no problem, you wrote that it was from another language. I was just pointing out that for me + is more logical then || for string concatenation. In JS you have a function that deals with string concatenation, but for me is easyer and nicer to use the + sign. But true, the language per se could use something different, let's say a tilde (~) or something else, unmistakable.

Thanks for the solution guys. I've actually realised my problem isnt sending extra 0's to my hardware. Its actually that philips pronto is sending ascii rather than decimal. Is it possible to send decimal?

Sure, just put hex values into a string.

"\x00\x01\x05\x09" -> 0159 Each number is a byte.

Be careful. How many bytes do you want to send for let us say the decimal value 159? You could send just one byte since a byte can have the values 0 through 255, or you could send one byte for each digit of the number as a small binary value as BluPhenix showed demonstrated.

The language when talking transmission of information is very "loose". People use the words decimal, binary, ascii, without too much regard for what they mean. It makes inter-person communications very difficult, although machines have no difficulty since they will interpret what they get according to what they are told (programmed) it is.

Eventually transmissions all involve sending bytes of information. The byte will always be a binary number in the range 0 to 255. The question comes down to what does the byte represent? An ASCII character? A small decimal integer?

I thought I posted a discussion on this but it definately is on my web site as a pronto communications primer called "Pronto PRO Communications". You might want to look at it.

I know it has been a while but I was going through some of my source code and found where I'd changed this up a bit.

Here is way to do this with least amount of code - Use String.slice() with negative parameter value.

function zeroFill3(value){
return String('000' + value).slice(-3);
}

Very nice. I slight change, passing in a string of zeros of length n will make it a general zero fill function with just a little more computational overhead.

function zeroFill(a,b) { return string(a+b).slice(-a.length) }

where a is a string of zeros of length equal to the fill size, and b is a string or integer to be filled/padded

called as zeroFill("000",52) should return "052". Probably don't need the String invocations since the overloaded + operator will always be concatenation if the left operand is a string. ergo

function frontFill(a,b) { return (a+b).slice(-a.length) }

Note the function name change as it will actually fill with whatever is provided as argument a.

I like Barry's approach better for general function.

However, from a pure performance-based approach, the only thing I don't like is having to provide "000" on each and every call to the function. IMO, way too much overhead (5 characters) for the compiler to deal with. If the function is called from 1000 different places then the "000" must be compiled 1000 different times. Sure I know that we are talking about milliseconds here, but in activity startup, they do add up.

On another note, I'd like to mention:

Bullet-proofing your code - Beware of runtime errors

In my original function, the String('000' + value) call guarantees that the outcome will be a string and as such, the .slice(-3) operation will never raise an error. If you use the function Barry supplied as-is, calling this function and passing an integral value of 5 for 'a' and an integral value of 12 for 'b' will cause a runtime error.

If I were coding a function for a public, general-use, toolkit, I would be sure to add the String() constructor to prevent support calls or errors in the field.