Typos by End User

[greekdish]

There is an issue I noticed. If an end user types in 350t, the script converts it to $350.00. This can cause issues because maybe the customer wanted to type in 3505, and the number should be $3,505.00....IMO, the script should kick out a NULL or 0. Im doing a calculator and accounting.js just keeps plugging away so long as there are SOME numbers from the end user....even if its text first.....such as thisshouldntwork350.....will get formatted to $350.00.

Thanks for a great script!

[wjcrowcroft]

This was a design decision actually, in order to save on long and complex regexes... when unformatting ('parsing') numbers, it can get endlessly complicated matching for patterns - separators, formats, precision, etc. - so I decided to sidestep it and just strip out all non-numeric characters (all it needs to know is what decimal separator you're using, default .)

I imagine the code would get a lot bigger (and the API more complicated) if doing exact matching and throwing errors or e.g. null on bad values.

If you think it could be improved, I'd recommend adding it as an extension to the main library so it would be an 'opt-in' kind of thing.

Let me know what you think!

[greekdish]

Thank you for replying.

Just a thought, but wouldnt it be easier programming to just return an error or null if anything else besides numbers were entered? IMO, I think its harder to have regexes that filter out the numbers, as opposed to just kicking back an error, no? Im not a programming expert by any means, but it almost seems the other way around.

Thanks

[wjcrowcroft]

Unfortunately not - it'd break many of the expected uses - for example, accounting.parse("HK$ 34,543.00 only") needs to return 34543 - the parse/unformat function is used before any formatting takes place