Well, in our case, this started out as a way for us to determine if the
variable we're dealing with is a number that we'd need to strip the commas
from. Due to the nature of our code, we only want to strip out the commas
if it's a number. For us, the bug actually works in our favor, because
that's really the only way to determine if it was a number. (Our other
alternative was to do an lsPareNumber() inside a try/catch block, which may
be the way we have to go if Adobe fixes the bug.
Scott
On Wed, Dec 4, 2013 at 8:27 AM, Jon Clausen <jon_clau...@silowebworks.com>wrote:
>
> Agreed. I would recommend stripping the commas out before you validate
> the number. They do strange things with calculations. For instance,
> numberFormat() converts 1,000 to 41274, as does JavaCast(int,1,000")
> or JavaCast(float,1,000"). I actually think its kind of incorrect that
> the default behavior for numberFormat(1000) returns 1,000 as it can mess up
> your calculations, but its been the default for so long, it would probably
> break backward compatibility for a bunch of apps.
>
>
>
>
> On Dec 3, 2013, at 7:35 PM, Adam Cameron <dacc...@gmail.com> wrote:
>
> >
> > It's a bug. There's no reason "1,000.00" should validate as a numeric
> value
> > of any kind; and "float" is a subset of numeric.
> >
> > Railo returns false for both. As does OpenBD.
> >
> > --
> > Adam
> >
> >
> >
> >
> > On 3 December 2013 22:05, Scott Brady <dsbr...@gmail.com> wrote:
> >
> >>
> >> The docs for isValid() imply that the type "numeric" and "float" are
> >> equivalent, in that they're listed together. However, they can yield
> >> different results:
> >> isValid("numeric","1,000.00") returns false
> >> isValid("float","1,000.00") returns true
> >>
> >> This came up as we're dealing with an issue of users entering "1,000.00"
> >> [or something similar] into a field, which can cause problems in one
> area
> >> of code where we need that value to be a valid number (i.e., we want to
> use
> >> it in a calculation, which results in an error). We can use
> >> lsParseNumber(0 around the value, but first we need to make sure it's a
> >> valid number anyway. So, we're somewhat forced into using
> >> isValid("float",....) which is fine.
> >>
> >> But, is this a bug with the actual isValid() function or is it more of a
> >> documentation error (i.e., behind the scenes, "float" and "numeric" are
> >> different and "1,000.00" is not a valid numeric but is a valid float)?
> >>
> >> Scott
> >>
> >> --
> >> -----------------------------------------
> >> Scott Brady
> >> http://www.scottbrady.net/
> >>
> >>
> >>
> >
> >
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Order the Adobe Coldfusion Anthology now!
http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion
Archive:
http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:357271
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
