Re: Ensuring numeric input
Try using isNumber --from the docs: the isNumber of value isNumber(value) isNumber(8) -- returns true isNumber(1+5) -- returns true isNumber(foo) -- returns false Dennis On Oct 26, 2005, at 8:34 PM, Michael J. Lew wrote: How can I prevent users from being able to make non-number values in a field? Simply preventing non-numeric keys is not enough because I need to prevent things that use characters that are in valid numbers to make non-numbers like 1.2.3 or -1.2-3. I thought it would be relatively easy, but it might not be. Here is the field script of a surprisingly complicated attempt: on keydown thekey if theKey is in "0123456789-." then --may be an allowable input -- but I still need to check whether the result would be a valid number. put value(the selectedLine) into thisLine --current number put length(thisLine) into thisLineLen put the selectedCHunk into sc --returns character locations from start of field --Need to find where the current line starts put offset(thisLine,me,min(0,word 2 of sc-thislinelen)) into thisLineStart --The characters to skip bit is an attempt to prevent the offset function -- from returning a match to an earlier line in the field. -- It needs the min function to prevent negative values. --Now see if the input would make a non-numeric result --First find where the selection point is in the line put word 2 of sc +1 - thisLineStart into theSelectionStartChar put word 4 of sc +1 - thisLineStart into theSelectionEndChar --I don't know why I had to add one to the values... put thisLineStart & return & theSelectionStartChar && theSelectionEndCHar --Now test the input in the relevant place put theKey into char theSelectionStartChar to theSelectionEndChar of thisLine --next line to help debugging --put thisLine & return & thisLineStart & return & theSelectionStartChar && theSelectionEndChar if thisLine & "0" is a number then --should be OK --Needs the appended zero to allow a line to start with a decimal point. pass KeyDown end if end if end keydown It seems to work, but it's an extraordinarily long and winding road to get to a simple end-point. What am I missing? Thanks, Michael -- Michael J. Lew Senior Lecturer Department of Pharmacology The University of Melbourne Parkville 3010 put "-1" is a number Victoria Australia Phone +613 8344 8304 ** New email address: [EMAIL PROTECTED] ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Michael, You can also add zero to it; if it is a number then the result will be empty. Paul Looney -Original Message- From: Dennis Brown <[EMAIL PROTECTED]> To: How to use Revolution Sent: Wed, 26 Oct 2005 21:07:09 -0400 Subject: Re: Ensuring numeric input Try using isNumber --from the docs: the isNumber of value isNumber(value) isNumber(8) -- returns true isNumber(1+5) -- returns true isNumber(foo) -- returns false Dennis On Oct 26, 2005, at 8:34 PM, Michael J. Lew wrote: > How can I prevent users from being able to make non-number values > in a field? Simply preventing non-numeric keys is not enough > because I need to prevent things that use characters that are in > valid numbers to make non-numbers like 1.2.3 or -1.2-3. > > I thought it would be relatively easy, but it might not be. Here is the field script of a surprisingly complicated attempt: > > on keydown thekey > if theKey is in "0123456789-." then --may be an allowable input > -- but I still need to check whether the result would be a > valid number. > put value(the selectedLine) into thisLine --current number > put length(thisLine) into thisLineLen > put the selectedCHunk into sc --returns character locations > from start of field > --Need to find where the current line starts > put offset(thisLine,me,min(0,word 2 of sc-thislinelen)) into > thisLineStart > --The characters to skip bit is an attempt to prevent the > offset function > -- from returning a match to an earlier line in the field. > -- It needs the min function to prevent negative values. > --Now see if the input would make a non-numeric result > --First find where the selection point is in the line > put word 2 of sc +1 - thisLineStart into theSelectionStartChar > put word 4 of sc +1 - thisLineStart into theSelectionEndChar > --I don't know why I had to add one to the values... > put thisLineStart & return & theSelectionStartChar && > theSelectionEndCHar > --Now test the input in the relevant place > put theKey into char theSelectionStartChar to > theSelectionEndChar of thisLine > --next line to help debugging > --put thisLine & return & thisLineStart & return & > theSelectionStartChar && theSelectionEndChar > if thisLine & "0" is a number then --should be OK > --Needs the appended zero to allow a line to start with a > decimal point. > pass KeyDown > end if > end if > end keydown > > > It seems to work, but it's an extraordinarily long and winding road to get to a simple end-point. What am I missing? > > Thanks, > Michael > > --> Michael J. Lew > > Senior Lecturer > Department of Pharmacology > The University of Melbourne > Parkville 3010 put "-1" is a number > Victoria > Australia > > Phone +613 8344 8304 > > ** > New email address: [EMAIL PROTECTED] > ** > ___ > use-revolution mailing list > [EMAIL PROTECTED] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > ___ use-revolution mailing list [EMAIL PROTECTED] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
[EMAIL PROTECTED] wrote: Michael, You can also add zero to it; if it is a number then the result will be empty. But is zero counted as zero, or would it add 0.1 in Intel chips? -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Thanks for the suggestions, but unfortunately it doesn't seem to be anywhere near that easy. A user can put the insertion point within a number and so I need to check before the character is entered whether the value will be a number after the new character is added at the insertion point. The new character may be at the start of a numeric string, in the middle or at the end. I can't find an easy function that gives the insertion point relative to the selectedLine. Most of the complexity of my script is in deciding where the insertion will be made in the line of interest. Still lacking a simple solution... At 8:56 PM -0500 26/10/05, [EMAIL PROTECTED] wrote: the isNumber of value isNumber(value) isNumber(8) -- returns true isNumber(1+5) -- returns true isNumber(foo) -- returns false Dennis Thanks, but the 'isnumber' function is the same as the 'is a number' that I used in my script. At 8:56 PM -0500 26/10/05, [EMAIL PROTECTED] wrote: You can also add zero to it; if it is a number then the result will be empty. Paul Looney Thanks, but that is not functionally different from simply using 'is a number'. Or is it? At 10:34 AM +1000 27/10/05, Michael J. Lew wrote: How can I prevent users from being able to make non-number values in a field? Simply preventing non-numeric keys is not enough because I need to prevent things that use characters that are in valid numbers to make non-numbers like 1.2.3 or -1.2-3. I thought it would be relatively easy, but it might not be. Here is the field script of a surprisingly complicated attempt: on keydown thekey if theKey is in "0123456789-." then --may be an allowable input -- but I still need to check whether the result would be a valid number. put value(the selectedLine) into thisLine --current number put length(thisLine) into thisLineLen put the selectedCHunk into sc --returns character locations from start of field --Need to find where the current line starts put offset(thisLine,me,min(0,word 2 of sc-thislinelen)) into thisLineStart --The characters to skip bit is an attempt to prevent the offset function -- from returning a match to an earlier line in the field. -- It needs the min function to prevent negative values. --Now see if the input would make a non-numeric result --First find where the selection point is in the line put word 2 of sc +1 - thisLineStart into theSelectionStartChar put word 4 of sc +1 - thisLineStart into theSelectionEndChar --I don't know why I had to add one to the values... put thisLineStart & return & theSelectionStartChar && theSelectionEndCHar --Now test the input in the relevant place put theKey into char theSelectionStartChar to theSelectionEndChar of thisLine --next line to help debugging --put thisLine & return & thisLineStart & return & theSelectionStartChar && theSelectionEndChar if thisLine & "0" is a number then --should be OK --Needs the appended zero to allow a line to start with a decimal point. pass KeyDown end if end if end keydown It seems to work, but it's an extraordinarily long and winding road to get to a simple end-point. What am I missing? Thanks, Michael -- Michael J. Lew Senior Lecturer Department of Pharmacology The University of Melbourne Parkville 3010 Victoria Australia Phone +613 8344 8304 ** New email address: [EMAIL PROTECTED] ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
On 10/26/05 10:58 PM, "Michael J. Lew" <[EMAIL PROTECTED]> wrote: > Thanks for the suggestions, but unfortunately it doesn't seem to be > anywhere near that easy. A user can put the insertion point within a > number and so I need to check before the character is entered whether > the value will be a number after the new character is added at the > insertion point. The new character may be at the start of a numeric > string, in the middle or at the end. I can't find an easy function > that gives the insertion point relative to the selectedLine. Most of > the complexity of my script is in deciding where the insertion will > be made in the line of interest. > > Still lacking a simple solution... Try this one (script of the field): on keydown whichKey if whichKey is among the chars of "01234567890.-" then put me into tTemp put word 2 of the selectedChunk into sChar put word 4 of the selectedChunk into eChar if eChar > sChar then -- some text is selected delete char sChar to eChar of tTemp end if put whichKey after char eChar of tTemp if isNumber(tTemp) then pass keyDown end if end keyDown Basically it checks to see if the end product would end up with a numeric value, and if so, it will allow the keystroke to happen. BTW: There was no reason to trap for backspace/delete as there isn't a way AFAIK to remove some or part of a number and have the end result *not* be a number. HTH, Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Richard, Funny you should mention this, inasmuch as this week is the week in which my class looks at computer risks and liability issues, including the pentium bug... @;-) Of course, they just told me today that they think that it is possible for a computerized voting scheme to have an error rate of <1%. Talk about captology... And this was after we talked about Win2000 having something on the order of 60 million lines of code... Judy On Wed, 26 Oct 2005, Richard Gaskin wrote: > [EMAIL PROTECTED] wrote: > > Michael, > > You can also add zero to it; if it is a number then the result will be > > empty. > > But is zero counted as zero, or would it add 0.1 in Intel chips? ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Judy Perry wrote: Of course, they just told me today that they think that it is possible for a computerized voting scheme to have an error rate of <1%. It's not the errors I'm concerned about as much as vulnerabilities and no audit trail. Bartcop's Second Law of Economics: "If someone makes a mistake that puts money in their pocket, you can bet they'll make that mistake again, and again, and again..." ;) -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
sez [EMAIL PROTECTED]: >How can I prevent users from being able to make non-number values in >a field? Simply preventing non-numeric keys is not enough because I >need to prevent things that use characters that are in valid numbers >to make non-numbers like 1.2.3 or -1.2-3. Something like this might work: local OldValue on keyDown put me into OldValue send "CheckMe" to me in 10 milliseconds -- adjust the "10" value as necessary to get good results pass keyDown end keyDown on CheckMe if (the value of me) is not a number then beep put OldValue into me end if end CheckMe The CheckMe handler can include whatever procedure you like for handling non-numeric input; I just went with 'beep' for audio feedback that Something Is Wrong, plus restoring the former (known to be numeric) value. Hope this helps... ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Ken Ray wrote:
BTW: There was no reason to trap for backspace/delete as there isn't a way
AFAIK to remove some or part of a number and have the end result *not* be a
number.
isNumber("-1")true
isNumber("-") false
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.361 / Virus Database: 267.12.5/149 - Release Date: 25/10/2005
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Richard, To make the world safe for Intel we could do the dirty work in a variable: on closeField put me into temp add 0 to temp--of course any number would do (0.1 or 10 or ?) if the result is not empy then answer "This is not a valid number:" end closeField Paul Looney -Original Message- From: Richard Gaskin <[EMAIL PROTECTED]> To: How to use Revolution Sent: Wed, 26 Oct 2005 19:25:53 -0700 Subject: Re: Ensuring numeric input [EMAIL PROTECTED] wrote: > Michael, > You can also add zero to it; if it is a number then the result will be > empty. But is zero counted as zero, or would it add 0.1 in Intel chips? -- Richard Gaskin Managing Editor, revJournal ___ Rev tips, tutorials and more: http://www.revJournal.com ___ use-revolution mailing list [EMAIL PROTECTED] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
> Thanks for the suggestions, but unfortunately it doesn't seem to be > anywhere near that easy. A user can put the insertion point within a > number and so I need to check before the character is entered whether > the value will be a number after the new character is added at the > insertion point. The new character may be at the start of a numeric > string, in the middle or at the end. I can't find an easy function > that gives the insertion point relative to the selectedLine. Most of > the complexity of my script is in deciding where the insertion will > be made in the line of interest. > > Still lacking a simple solution... It depends on what you are looking for. If you are looking for integer values, you can use "x is an integer", otherwise you can use "x is a number" to check the result. How about something like this? You can store a last legitimate value as a custom property. If the user inputs something that doesn't fit, you can simply replace it with the last correct value. This is not tested, but you shouldn't have too many problems with it. I didn't test the key pressed. I tested the result. Good luck. On keyup whichkey put the selectedchunk into tselchunk if value(me) is a number then put value(me) into the storedvalue of me put value(me) into me else put the storedvalue of me into me end if select tselchunk On keyup Regards, Raymond E. Griffith > > At 8:56 PM -0500 26/10/05, [EMAIL PROTECTED] wrote: >> the isNumber of value >> isNumber(value) >> >> isNumber(8) -- returns true >> isNumber(1+5) -- returns true >> isNumber(foo) -- returns false >> >> Dennis > > Thanks, but the 'isnumber' function is the same as the 'is a number' > that I used in my script. > > > At 8:56 PM -0500 26/10/05, [EMAIL PROTECTED] wrote: >> You can also add zero to it; if it is a number then the result will be >> empty. >> Paul Looney > > Thanks, but that is not functionally different from simply using 'is > a number'. Or is it? > > At 10:34 AM +1000 27/10/05, Michael J. Lew wrote: >> How can I prevent users from being able to make non-number values in >> a field? Simply preventing non-numeric keys is not enough because I >> need to prevent things that use characters that are in valid numbers >> to make non-numbers like 1.2.3 or -1.2-3. >> >> I thought it would be relatively easy, but it might not be. Here is >> the field script of a surprisingly complicated attempt: >> >> on keydown thekey >> if theKey is in "0123456789-." then --may be an allowable input >> -- but I still need to check whether the result would be a valid number. >> put value(the selectedLine) into thisLine --current number >> put length(thisLine) into thisLineLen >> put the selectedCHunk into sc --returns character locations from >> start of field >> >> --Need to find where the current line starts >> put offset(thisLine,me,min(0,word 2 of sc-thislinelen)) into >> thisLineStart >> --The characters to skip bit is an attempt to prevent the offset function >> -- from returning a match to an earlier line in the field. >> -- It needs the min function to prevent negative values. >> >> --Now see if the input would make a non-numeric result >> --First find where the selection point is in the line >> put word 2 of sc +1 - thisLineStart into theSelectionStartChar >> put word 4 of sc +1 - thisLineStart into theSelectionEndChar >> --I don't know why I had to add one to the values... >> put thisLineStart & return & theSelectionStartChar && theSelectionEndCHar >> --Now test the input in the relevant place >> put theKey into char theSelectionStartChar to >> theSelectionEndChar of thisLine >> >> --next line to help debugging >> --put thisLine & return & thisLineStart & return & >> theSelectionStartChar && theSelectionEndChar >> >> if thisLine & "0" is a number then --should be OK >> --Needs the appended zero to allow a line to start with a decimal >> point. >> pass KeyDown >> end if >> end if >> end keydown >> >> >> It seems to work, but it's an extraordinarily long and winding road >> to get to a simple end-point. What am I missing? >> >> Thanks, >> Michael > > ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Ensuring numeric input
.2 is a number . is just a period, not a number -2 is a number - is just a minus sign, not a number -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Ray Sent: Thursday, October 27, 2005 12:16 AM To: Use Revolution List Subject: Re: Ensuring numeric input On 10/26/05 10:58 PM, "Michael J. Lew" <[EMAIL PROTECTED]> wrote: > Thanks for the suggestions, but unfortunately it doesn't seem to be > anywhere near that easy. A user can put the insertion point within a > number and so I need to check before the character is entered whether > the value will be a number after the new character is added at the > insertion point. The new character may be at the start of a numeric > string, in the middle or at the end. I can't find an easy function > that gives the insertion point relative to the selectedLine. Most of > the complexity of my script is in deciding where the insertion will > be made in the line of interest. > > Still lacking a simple solution... Try this one (script of the field): on keydown whichKey if whichKey is among the chars of "01234567890.-" then put me into tTemp put word 2 of the selectedChunk into sChar put word 4 of the selectedChunk into eChar if eChar > sChar then -- some text is selected delete char sChar to eChar of tTemp end if put whichKey after char eChar of tTemp if isNumber(tTemp) then pass keyDown end if end keyDown Basically it checks to see if the end product would end up with a numeric value, and if so, it will allow the keystroke to happen. BTW: There was no reason to trap for backspace/delete as there isn't a way AFAIK to remove some or part of a number and have the end result *not* be a number. HTH, Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Ensuring numeric input
don't forget many use commas for decimal points too... Tildes for 1'000's etc... cheers X > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Lynch, Jonathan > Sent: Thursday, October 27, 2005 3:34 PM > To: How to use Revolution > Subject: RE: Ensuring numeric input > > .2 is a number > . is just a period, not a number > > -2 is a number > - is just a minus sign, not a number > > > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ken Ray > Sent: Thursday, October 27, 2005 12:16 AM > To: Use Revolution List > Subject: Re: Ensuring numeric input > > On 10/26/05 10:58 PM, "Michael J. Lew" > <[EMAIL PROTECTED]> wrote: > > > Thanks for the suggestions, but unfortunately it doesn't seem to be > > anywhere near that easy. A user can put the insertion point > within a > > number and so I need to check before the character is > entered whether > > the value will be a number after the new character is added at the > > insertion point. The new character may be at the start of a numeric > > string, in the middle or at the end. I can't find an easy function > > that gives the insertion point relative to the > selectedLine. Most of > > the complexity of my script is in deciding where the > insertion will be > > made in the line of interest. > > > > Still lacking a simple solution... > > Try this one (script of the field): > > on keydown whichKey > if whichKey is among the chars of "01234567890.-" then > put me into tTemp > put word 2 of the selectedChunk into sChar > put word 4 of the selectedChunk into eChar > if eChar > sChar then -- some text is selected > delete char sChar to eChar of tTemp > end if > put whichKey after char eChar of tTemp > if isNumber(tTemp) then pass keyDown > end if > end keyDown > > Basically it checks to see if the end product would end up > with a numeric value, and if so, it will allow the keystroke > to happen. > > BTW: There was no reason to trap for backspace/delete as > there isn't a way AFAIK to remove some or part of a number > and have the end result *not* be a number. > > HTH, > > Ken Ray > Sons of Thunder Software > Web site: http://www.sonsothunder.com/ > Email: [EMAIL PROTECTED] > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage > your subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage > your subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
On 10/27/05 5:19 AM, "Alex Tweedly" <[EMAIL PROTECTED]> wrote:
> Ken Ray wrote:
>
>>
>> BTW: There was no reason to trap for backspace/delete as there isn't a way
>> AFAIK to remove some or part of a number and have the end result *not* be a
>> number.
>>
>>
> isNumber("-1")true
> isNumber("-") false
>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
On 10/27/05 5:19 AM, "Alex Tweedly" <[EMAIL PROTECTED]> wrote:
> Ken Ray wrote:
>
>>
>> BTW: There was no reason to trap for backspace/delete as there isn't a way
>> AFAIK to remove some or part of a number and have the end result *not* be a
>> number.
>>
>>
> isNumber("-1")true
> isNumber("-") false
>
You're right! Good catch, Alex!
Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: [EMAIL PROTECTED]
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
On 10/27/05 8:34 AM, "Lynch, Jonathan" <[EMAIL PROTECTED]> wrote: > .2 is a number > . is just a period, not a number > > -2 is a number > - is just a minus sign, not a number True... but that raises another UI issue - if the field has ".2" in it and someone attempts to delete the "2", do we keep the "." by itself in the field, hoping someone will type another number and then tray it on closeField to provide an alert? Or do we remove the decimal point as well to empty the field? And if we *do* remove the decimal, how would that be different from having an empty field and typing a decimal point to start a decimal number; before the actual number is typed, there's just a decimal point in the field... Hmm... Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Ensuring numeric input
I had to deal with this issue in my Task Mage app. When people enter dates into the date column, or times into the time column, it has to be a real date or real time, or else it will cause problems. I addressed this in two ways. In the keydown handler I only allow appropriate characters. In the exitfield handler, the script tries to interpret what they wrote and make it conform to the proper date or time format. If it does not conform, the field is reverted to empty. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Ray Sent: Thursday, October 27, 2005 11:53 AM To: Use Revolution List Subject: Re: Ensuring numeric input On 10/27/05 8:34 AM, "Lynch, Jonathan" <[EMAIL PROTECTED]> wrote: > .2 is a number > . is just a period, not a number > > -2 is a number > - is just a minus sign, not a number True... but that raises another UI issue - if the field has ".2" in it and someone attempts to delete the "2", do we keep the "." by itself in the field, hoping someone will type another number and then tray it on closeField to provide an alert? Or do we remove the decimal point as well to empty the field? And if we *do* remove the decimal, how would that be different from having an empty field and typing a decimal point to start a decimal number; before the actual number is typed, there's just a decimal point in the field... Hmm... Ken Ray Sons of Thunder Software Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Recently, Lynch, Jonathan wrote: >> .2 is a number >> . is just a period, not a number >> >> -2 is a number >> - is just a minus sign, not a number > > True... but that raises another UI issue - if the field has ".2" in it > and > someone attempts to delete the "2", do we keep the "." by itself in the > field, hoping someone will type another number and then tray it on > closeField to provide an alert? Or do we remove the decimal point as > well to > empty the field? And if we *do* remove the decimal, how would that be > different from having an empty field and typing a decimal point to start > a > decimal number; before the actual number is typed, there's just a > decimal > point in the field... I'm wondering if all this character checking is working too hard. For reference, I just looked at two higher end graphics apps: Photoshop and Freehand. Photoshop simply evaluates the characters in the field on enter/return and throw up a dialog if it finds a non-number. Freehand (interestingly) replaces non-numeric values with the smallest acceptable numeric value (0.01). Perhaps this could be an option. Regards, Scott Rossi Creative Director Tactile Media, Multimedia & Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Ken Ray wrote: On 10/27/05 8:34 AM, "Lynch, Jonathan" <[EMAIL PROTECTED]> wrote: .2 is a number . is just a period, not a number -2 is a number - is just a minus sign, not a number True... but that raises another UI issue - if the field has ".2" in it and someone attempts to delete the "2", do we keep the "." by itself in the field, hoping someone will type another number and then tray it on closeField to provide an alert? Or do we remove the decimal point as well to empty the field? And if we *do* remove the decimal, how would that be different from having an empty field and typing a decimal point to start a decimal number; before the actual number is typed, there's just a decimal point in the field... Hmm... Which is why most of us, I think, check the entry on closefield rather than dynamically. If you do that, none of the other problems come up. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Yep, Which came first.. the decimal or the digit, or the comma or the space to indicate the end of the word or multiple numbers or dollar signs Perhaps 'hinting' by inserting a '?' as a place holder until a valid number is found. Rather complicated when dealing with humans, eh? Jim Ault Las Vegas On 10/27/05 8:53 AM, "Ken Ray" <[EMAIL PROTECTED]> wrote: > On 10/27/05 8:34 AM, "Lynch, Jonathan" <[EMAIL PROTECTED]> wrote: > >> .2 is a number >> . is just a period, not a number >> >> -2 is a number >> - is just a minus sign, not a number > > True... but that raises another UI issue - if the field has ".2" in it and > someone attempts to delete the "2", do we keep the "." by itself in the > field, hoping someone will type another number and then tray it on > closeField to provide an alert? Or do we remove the decimal point as well to > empty the field? And if we *do* remove the decimal, how would that be > different from having an empty field and typing a decimal point to start a > decimal number; before the actual number is typed, there's just a decimal > point in the field... > > Hmm... > > Ken Ray > Sons of Thunder Software > Web site: http://www.sonsothunder.com/ > Email: [EMAIL PROTECTED] > > ___ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Lynch, Jonathan wrote: I had to deal with this issue in my Task Mage app. When people enter dates into the date column, or times into the time column, it has to be a real date or real time, or else it will cause problems. I addressed this in two ways. In the keydown handler I only allow appropriate characters. In the exitfield handler, the script tries to interpret what they wrote and make it conform to the proper date or time format. If it does not conform, the field is reverted to empty. That sounds like a good approach, *except* (for someone as poor a typist as me) - I type 2005/0w/14 (i.e. mis-hit the 'w' below the '2' that I was aiming for) - hit return (or tab or ...) - and because it's not a valid date, the whole lot goes and I need to start typing from scratch ?? Some days, I'd never complete typing a date ! :-) Hopefully, you allow some way to get back the invalid typing so I can just edit that. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.361 / Virus Database: 267.12.5/149 - Release Date: 25/10/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Ensuring numeric input
It's a matter of interpretation... My date interpretation will automatically complete a date. 11/9 becomes 11/09/05 (this year, next year it will be 11/09/06. 1/2 becomes 1/02/05 12/0w/05 would be automatically converted to 12/01/05... 2005/0w/14 would be converted to 12/01/2014... This last one is because the American convention is Mo/Day/Year, and the program is not set up for the year/mo/day convention (although it could be, if that were ever an issue). It can't be perfect, some things just cannot be interpreted. In my situation, I cannot afford to have an invalid date in a date field, or it will cause a cascading list of problems - so I have to be rigid about that. But I see what you mean, if possible, it would be better to be nice to your user and allow them to correct an invalid date rather than have to type it over. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Tweedly Sent: Thursday, October 27, 2005 2:14 PM To: How to use Revolution Subject: Re: Ensuring numeric input Lynch, Jonathan wrote: >I had to deal with this issue in my Task Mage app. When people enter >dates into the date column, or times into the time column, it has to be >a real date or real time, or else it will cause problems. > >I addressed this in two ways. In the keydown handler I only allow >appropriate characters. > >In the exitfield handler, the script tries to interpret what they wrote >and make it conform to the proper date or time format. If it does not >conform, the field is reverted to empty. > > > That sounds like a good approach, *except* (for someone as poor a typist as me) - I type 2005/0w/14 (i.e. mis-hit the 'w' below the '2' that I was aiming for) - hit return (or tab or ...) - and because it's not a valid date, the whole lot goes and I need to start typing from scratch ?? Some days, I'd never complete typing a date ! :-) Hopefully, you allow some way to get back the invalid typing so I can just edit that. -- Alex Tweedly http://www.tweedly.net -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.361 / Virus Database: 267.12.5/149 - Release Date: 25/10/2005 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Sorry Ken. Your script works well in a one-line field, but I need it to work in a many line field (maybe I didn't say that in the first place). At 12:27 AM -0500 27/10/05, [EMAIL PROTECTED] wrote: Try this one (script of the field): on keydown whichKey if whichKey is among the chars of "01234567890.-" then put me into tTemp put word 2 of the selectedChunk into sChar put word 4 of the selectedChunk into eChar if eChar > sChar then -- some text is selected delete char sChar to eChar of tTemp end if put whichKey after char eChar of tTemp if isNumber(tTemp) then pass keyDown end if end keyDown Basically it checks to see if the end product would end up with a numeric value, and if so, it will allow the keystroke to happen. BTW: There was no reason to trap for backspace/delete as there isn't a way AFAIK to remove some or part of a number and have the end result *not* be a number. HTH, Ken Ray At 5:44 AM -0500 27/10/05, Richard Gaskin wrote: Judy Perry wrote: > Of course, they just told me today that they think that it is possible for > a computerized voting scheme to have an error rate of <1%. It's not the errors I'm concerned about as much as vulnerabilities and no audit trail. Bartcop's Second Law of Economics: "If someone makes a mistake that puts money in their pocket, you can bet they'll make that mistake again, and again, and again..." This will get me into trouble if anyone notices it here at the bottom: It is very important to recognize the folly of corruptible voting machines and to accept the possibility that elections are rigged. However, it is MUCH more important that people think about why they voted the way they did. They shouldn't be misled in the same way a second (third?) time. A little reflection and self-knowledge is called for: half of us owe the other half a confession of mea culpa. -- Michael J. Lew Senior Lecturer Department of Pharmacology The University of Melbourne Parkville 3010 Victoria Australia Phone +613 8344 8304 ** New email address: [EMAIL PROTECTED] ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Thank you all for your input into my problem. I have now settled on a solution using a combination of a keydown filter and a handler triggered on closeField. In the field scripts: on keydown thekey if theKey is in "01234567890-.," then --note comma added for MisterX pass keyDown end if end keydown on closeField checkFieldForValidNumbers(the id of me) end closeField And in the stack script: on checkFieldForValidNumbers pfieldID put fld ID pFieldID into tdata put 0 into lineNum repeat for each line tline in tdata add 1 to lineNum if tline is not a number then beep Answer "Please ensure that all values are valid numbers." select line lineNum of field id pFieldID exit to top end if end repeat end checkFieldForValidNumbers I am assuming that the number() function will be OK with commas as decimal places in coutries where that is the norm, but I'm not really sure. Xavier, can you check that the scripts work OK for you please? -- Michael J. Lew Senior Lecturer Department of Pharmacology The University of Melbourne Parkville 3010 Victoria Australia Phone +613 8344 8304 ** New email address: [EMAIL PROTECTED] ** ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Ensuring numeric input
Ooops. Late again. My standard numberField solution is similar to Michael's
but simpler as it doesn't need to handle multiple lines. It does, hoever,
validate pre- rather than post-process and restores the old value if
necessary...
local lOldValue
on openField
put me into lOldValue
end openField
on keyDown tKey
if (tKey=".") AND ("." is in me) then exit keyDown
else if (tKey="-") AND (me="") then pass keyDown
else if tKey is in "0123456789." then pass keyDown
end keyDown
on closeField
set the numberFormat to "0.00"
put line 1 of me into me
if me is NOT a number then put lOldValue into me
else add 0 to me
end closeField
/H
FLCo
Home of the Scripter's Scrapbook
www.FlexibleLearning.com/ssbk.htm
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
