Google Groups unterstützt keine neuen Usenet-Beiträge oder ‑Abos mehr. Bisherige Inhalte sind weiterhin sichtbar.

regexpr and decimal point?

2 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Jeffrey Hobbs

ungelesen,
09.08.1999, 03:00:0009.08.99
an Gerald Pollack
Gerald Pollack wrote:
> bind .e <KeyPress> {
> puts [regexp {\.} %K]

The regexp is working, the binding is not. %K means Keysym, which for
'.' is "period". You want %A. However, you might also look at the
sample code for this in the Tk Usage FAQ:
http://www.purl.org/net/hobbs/tcl/faqs/tk/

--
Jeffrey Hobbs The Tcl Guy
jeffrey.hobbs at scriptics.com Scriptics Corp.

Gerald Pollack

ungelesen,
10.08.1999, 03:00:0010.08.99
an
I'm trying to use regexp to test whether characters typed into an entry
widget are legal for real numbers, i.e. the numberals 0-9 and a decimal
point. I've been unable to get regexp to work correctly for the decimal
point. Practical Programming in Tcl/Tk says (Table 11-2) that {\.}
should work, but it doesn't on my system (linux, tcl 8.0.3). Here's how
I've tested it:

entry .e
pack .e


bind .e <KeyPress> {
puts [regexp {\.} %K]

I expect that the puts will write 1 to the console when I type ".", and
0 for everything else. But it writes 0 even for ".". I've played with
the regexp statement (i.e. to detect only numberals, numerals and
carriage returns, etc.), and everything seems to work except for the
period. Can anyone tell me what I'm doing wrong?

Thanks,

--
Gerald Pollack
Dept. of Biology, McGill University

two_...@my-deja.com

ungelesen,
10.08.1999, 03:00:0010.08.99
an
In article <37AF8B0A...@bio1.lan.mcgill.ca>,

Gerald Pollack <gpol...@bio1.lan.mcgill.ca> wrote:
> I'm trying to use regexp to test whether characters typed into an
entry
> widget are legal for real numbers, i.e. the numberals 0-9 and a
decimal
> point. I've been unable to get regexp to work correctly for the
decimal
> point. Practical Programming in Tcl/Tk says (Table 11-2) that {\.}
> should work, but it doesn't on my system (linux, tcl 8.0.3). Here's
how

Even if you get the . to work this won't keep someone from entering two
or more periods as in 3.485.43 which would not be a legal number. Also
have you considered the possibility that the real number may be negative
and be entered with a positive or negative exponent like 1.43e+04.

I recently had a similar "delima" and decided to wait until I actually
need the value to check to see if it is a valid floating point number.
At first I thought I could do this with a regular expression check. But
one can actually enter a valid number in a number of different ways.

Below I have included a procedure I called NotANumber which will return
a 1 if the passed in value in not valid. Maybe there is a simpler way
but I don't think a regexp can account for all the possibilities.

##############################################################################
#
# NotANumber
#
# Procedure used to determine if the argument is not a valid numerical
value.
# The only characters allowed are the "0123456789eE.+-" Hopefully all
of the
# possibilities have been taken care of.
#
# A 1 is returned if the string does not represent a numerical value
and
# a 0 if it does.
#
##############################################################################

proc NotANumber {v} {

set nv [string tolower $v]

# First check to see if there any characters not associated with
numbers, if
# so, then it is not a number.

foreach c [split $nv {}] {
if { [regexp {[^-+0-9e.]} $c] } {return 1}
}

# Check to see if there are 2 or more periods or decimal points. If
so, then
# consider the argument not a number.

if {[regsub -all {\.} $nv "Q" junk] >= 2} {return 1}

# If there are no numbers in the string then it's not a number.

if {[regsub -all {[0-9]} $nv "Q" junk] == 0} {return 1}

# If there is a + or - since present at the beginning of the string get
rid
# of it to aid further testing. Also, replace any + signs with - signs
to
# aid in further checking.

regsub {^[-+]} $nv "" nv
regsub -all {\+} $nv "-" nv

# If there is more than one - now, it is not a number.

if {[regsub -all {\-} $nv "Q" junk] >= 2} {return 1}

# If there is a - sign present (remember all + were turned to -), it
must be
# preceded by an 'e'.

set ie [string first e $nv]
set im [string first "-" $nv]
if {$im == 0 || $ie == 0} {return 1}
if {$im >=1} {
if {$ie+1 != $im} {return 1}
}

# Remove the minus if present by this stage.

regsub -all {\-} $nv "" nv

# By this stage the only thing left (I think) is to make sure that if a
"."
# is present that it occurs before the e if present.

set ip [string first "." $nv]
if {$ip >=0 && $ie >= 0} {
if {$ip > $ie} {return 1}
}

return 0
}

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Thomas Rassinger

ungelesen,
11.08.1999, 03:00:0011.08.99
an
> I'm trying to use regexp to test whether characters typed into an entry
> widget are legal for real numbers, i.e. the numberals 0-9 and a decimal
> point. I've been unable to get regexp to work correctly for the decimal
> point. Practical Programming in Tcl/Tk says (Table 11-2) that {\.}
> should work, but it doesn't on my system (linux, tcl 8.0.3).


I had exact the same problem under WinNT. I don't know why but the
regular expression "\\." works perfectly. Try it.

Regards,
Thomas Rassinger

George A. Howlett

ungelesen,
11.08.1999, 03:00:0011.08.99
an
Gerald Pollack <gpol...@bio1.lan.mcgill.ca> wrote:
: I'm trying to use regexp to test whether characters typed into an entry

: widget are legal for real numbers, i.e. the numberals 0-9 and a decimal
: point. I've been unable to get regexp to work correctly for the decimal
: point. Practical Programming in Tcl/Tk says (Table 11-2) that {\.}
: should work, but it doesn't on my system (linux, tcl 8.0.3). Here's how
: I've tested it:

: entry .e
: pack .e
: bind .e <KeyPress> {
: puts [regexp {\.} %K]

It's hard to validate the entry this way at each keystroke because
it's easy to type invalid partial numeric sequences. If your routine
checks for just for digits and decimal points, you disallow scientific
notation. If you test the whole string after each keypress, you can
then fail lots of partial sequences.

It's easier to require a Return to set the value. On the Return key
you can test the whole string, since it has to be complete at this
point. You can simply try to scan the string to see if it's a valid
number.

set actualValue {}

bind .e <KeyPress-Return> {
if { ![IsANumber [.e get]] } {
.e delete 0 end
.e insert 0 $actualValue
} else {
set actualValue [.e get]
}
}

proc IsANumber { string } {
scan %g $string dummy
}

--gah

Donal K. Fellows

ungelesen,
12.08.1999, 03:00:0012.08.99
an
In article <7opmjo$kbl$1...@nnrp1.deja.com>, two_...@my-deja.com writes
>In article <37AF8B0A...@bio1.lan.mcgill.ca>,

> Gerald Pollack <gpol...@bio1.lan.mcgill.ca> wrote:
>> I'm trying to use regexp to test whether characters typed into an
>entry
>> widget are legal for real numbers, i.e. the numberals 0-9 and a
>decimal
>> point. I've been unable to get regexp to work correctly for the
>decimal
>> point. Practical Programming in Tcl/Tk says (Table 11-2) that {\.}
>> should work, but it doesn't on my system (linux, tcl 8.0.3). Here's
>how
>
>Even if you get the . to work this won't keep someone from entering two
>or more periods as in 3.485.43 which would not be a legal number. Also
>have you considered the possibility that the real number may be negative
>and be entered with a positive or negative exponent like 1.43e+04.
>
>I recently had a similar "delima" and decided to wait until I actually
>need the value to check to see if it is a valid floating point number.
>At first I thought I could do this with a regular expression check. But
>one can actually enter a valid number in a number of different ways.

In fact, it is important to not check the validity of the number too
early, since you can get invalid strings temporarily in the process of
entering a valid number ("1.43e+" is not a valid float, but it is
naturally encountered in the process of entering a valid float.) This
just goes to show that linking an entry widget directly to the value
that it is being used to modify is not generally a good idea when you
need validation. Instead, you need to perform your validations when the
field is "done" with, and you should have some mechanism for alerting
people to problems that the validation process picks up (e.g. by calling
[bell] and focussing on the widget with a problem, since that alerts
people who are not looking at the screen during data entry - a fairly
common occurrence.)

Much more cunning and usable schemes can be used too, but they take
rather too much effort to explain here right now! (We would be
interested in hearing of anything concocted by anyone else though... :^)

Donal.
--
Donal K. Fellows (at home)
--
FOOLED you! Absorb EGO SHATTERING impulse rays, polyester poltroon!!

0 neue Nachrichten