When is a Number a Number?

[dunbarx]

@Mikey I assumed you meant instead. Can you give a short example?

But in virtually all cases, I believe that validating the keyPress well before anything gets placed into the field is the way to go.

Craig

[Mikey]

I would agree that validating the key press is a good thing to do. It just becomes harder if you want to allow more flexibility with the field.
What I was suggesting just off the cuff without testing it was letting the user have at the field, and validate the contents after they're done with it, for example, by adding 0 to the contents and checking that if the normal number checks don't work.

[MaxV]

I want a Field to only have numbers entered into ie. no text.

So I looked at the code in the Lessons Book on page 127 and put this together for my Field script

Code: Select all

on keyDown thekey
   If thekey is not a number then answer information "Must be a number"
   else pass keyDown 
PUT me into nareasqm 
end keyDown

However when I test it, it will not let me enter a decimal point eg. 27.5 yet the Dictionary says a Number can have decimal place. So is this a glitch with LC or is my code doing something to make it think it's an Integer

Don't EVER use keydown for this purpose, but use closeField, because user can mistype and correct it. Closefield is activated when the user finished to write, the content changed and he exit the field.

[dunbarx]

Max.

Don't EVER ...

What you propose so strongly is, to me, more a matter of the user experience than the best way to solve the problem. In other words, a matter of style.

In yet other words, is it better to deny the entry, char by char, of illegal keypresses, or is it better to deny the totality of the complete contents of the field?

I go with the first.

Craig

[dunbarx]

Given that I like to validate keyPresses instead of the contents of the field, I think this is pretty good:

Code: Select all

 on keyDown tKey
   if (tkey is in ".+--" and me is empty) or (tKey is in "0123456789." and me & tKey is a number)
   then pass keyDown
end keyDown

Untested, but this either allows a valid starting char in an empty field, or tests the appending of the most recent (validated) char to the contents of the field, and if that string is a number, it allows the char to be added.

It seems to work when one tries to add a bogus char to the interior of the field as well. The test appending a bogus char also works as well in the middle. Just lagniappe.

Craig

[MaxV]

Max.

Don't EVER ...

What you propose so strongly is, to me, more a matter of the user experience than the best way to solve the problem. In other words, a matter of style.

In yet other words, is it better to deny the entry, char by char, of illegal keypresses, or is it better to deny the totality of the complete contents of the field?

I go with the first.

Craig

Well, I used EVER to stress the point. Deny char by char create a lot of problems in many, many context. If user don't finish to type what he wants, you can't know what it really meant. This case is for numbers, but letters, words, any possible situation is much better closeField, because there are many unimaginable situation that you can't predict the error until the user finish to type.
For example in some asian languages, user type different keys and some combination change the typed chars to other (like, you press "USD" and after typing "D", the "USD" become "$").
Or some typing softwares for quite blind people. If you block user to finish to type, you risk that he will never be able to type.
Denying char by char you risk a situation as the famous error message "Mouse not found, click here with mouse to proceed."

[dunbarx]

Max.

Ah. You make a point if a multi-char string is processed as a single "entry". I suppose that if there were a complete list of such combinations, they could be addressed on a case by case basis.

Just goes to show that nothing is as simple as is seems. But I live in the United States, where everyone is as simple as they seem.

Craig

[bogs]

<- PDS
{Pretty Dang Simple}