Hi Rob,
The requirement was to check if a string is a number, attempting to
prevent keyboard entry of characters other than 0 to 9 is a bad way to
achieve that.
I prefer to leave it to the OP to a) define his requirements and b) decide
which solution best satisfies him.
The OP, and anyone who discovers this thread looking for something
like "check string is number".
Posterity? I'm with ya now.
Extensible? By adding more character codes I guess. But simply
restricting the characters that can be entered does not ensure a
number will result. If you allow decimal points for decimal numbers,
then 1.2.3 is likely not considered a "number" by most but will be
allowed by your solution.
Imagine having to count the number of dots in a string? How awful! Yes, it's
called "programmin g" Rob, and not very difficult code at that. Are any of
these problems that you throw up meant to be show-stoppers? Is there some
mystery to the functionality in isNaN() that you feel can never be
reproduced in the outside world?
If it's the re-inventing-the-wheel that bothers you then would it not be
possible to trap the keycode and append it to the current value (from
CharCode()?) and then use the omnipotent isNan(newString ) to decide whetehr
to return true or false?
Look, I'd personally much prefer to see style="text-transform:
edit-mask(##,##9.99) " but, in the absence of that, I don't think it would
take the OP (or anyone) too long to come up with a isValidNumber() ,
isValidInteger, isValidEmail(), isValidPhoneNum ber() etc, etc.
But I'm certainly not trying to impose my views on everyone. If RobG thinks
field-level validation is the work of the devil then by all means stick with
the submit key! Who cares that the error was some 20 fields ago and has had
a ripple effect throughout the other fields on the screen, you make that
User go back and do it all again. Yes, block-mode validation and IBM 3270s,
oh happy days! Maybe give them all punch-cards?
As far as Java Applets and predictive text functionality goes, RobG and Pol
Pot say "Do it at the server! The old way much better.", and if God wanted
us to support Ajax then he would've made us all Dutch!
And at the end of if all, users can completely bypass your scheme by
using copy and paste.
Rob, this is all about assisting users in having a pleasurable, responsive,
and productive navigation across the screen. If they're hell-bent on getting
around something then the server will pick it up. But, as I said above,
edit-mask text transformation would be nice.
Try to get beyond grade 6. Perhaps you'd like to explain your
solution for the usability issues raised above?
Although in hindsight my comment was inappropriate, it was just a more
overly familiar form of "I think you're very much mistaken" rather than
abusive. As for usability issues, I leave it up to the OP/readers to decide
if there is any merit in the approach that I've outlined.
When it comes to "usability" and the web in general, I've found that people
are more than willing to put up with anything including that context-devoid
and connectionless pile-of-pooh that is HTTP with its dodgy cookies, session
Id's, expiration dates and Session Hijacking. But hey, each to their own,
it's a broad church.
Regards Richard Maher
"RobG" <rg***@iinet.ne t.auwrote in message
news:11******** **************@ x40g2000prg.goo glegroups.com.. .
On Aug 28, 11:07 pm, "Richard Maher" <maher...@hotsp amnotmail.com>
wrote:
Hi Rob,
That must be the worst way to go about it. It has many usability
issues, including preventing decimal numbers, scientific notation,
signs, and so on.
Maybe you're right, maybe Eggie did want scientific notation and was
calculating pie to infinity with a reverse Polish calculator.
The requirement was to check if a string is a number, attempting to
prevent keyboard entry of characters other than 0 to 9 is a bad way to
achieve that.
[...]
Either way, who gives a toss?
The OP, and anyone who discovers this thread looking for something
like "check string is number".
If you present a solution that you know has limitations, best to spell
them out rather than leave it for others to discover by trial and
error. It will often be their users who will need to submit to the
trial and endure the errors.
All I did was offer Egmont an extensible alternative for what he was
trying
to do.
Extensible? By adding more character codes I guess. But simply
restricting the characters that can be entered does not ensure a
number will result. If you allow decimal points for decimal numbers,
then 1.2.3 is likely not considered a "number" by most but will be
allowed by your solution.
Your "solution" also prevents the use of backspace or delete to remove
incorrect entries - more keycodes to add. And maybe the user wants to
use the cursor keys too, hey more keycodes. Maybe they also like to
use tab to move to the next field... how many keycodes do you think
you will end up adding just to allow integers and floats?
And at the end of if all, users can completely bypass your scheme by
using copy and paste.
If you choose to censor the material available to him in his fact
gathering
Censor? I don't have the power to do that, and wouldn't if I did.
then I'm obliged to float the possibility that your prejudice and
myopia have you once again talking out of your arse.
Try to get beyond grade 6. Perhaps you'd like to explain your
solution for the usability issues raised above?
--
Rob
