isnumeric compile error...

**Salad** · Jul 28 '08, 02:55 AM

Re: isnumeric compile error...

MLH wrote:

I have tested the following in immed window:
>
?isnumeric(1)
True
?isnumeric(1.)
True
?isnumeric(1.2)
True
?isnumeric(1.2. 2)
>
The last one does not print True nor False.
Instead, A97 complains of a compile error.
I would really prefer False, should such be
the case. What's the best way not to be
bothered with the error and just assume
False is returned?
>
Experimenting with CStr was not fruitful
because 1.2.2 is neither a valid numeric
expression nor a valid string expression.

Why is it not a valid string?

So, what can I do if I find myself needing
to process ?CStr(1.2.2) in the same way
?CStr("1.2.2") would be processed.

Put quotes around it. You're in debug, not a form or report or query or
table.

If a user enters 1.2.2 in an unbound text-
box expecting a valid numeric entry, I
would like very much to determine, in
code, that it is NOT a valid numeric.
But IsNumeric(1.2.2 ) is not the answer
and neither is IsNumeric(CStr( 1.2.2)). So
what do I do?

I created a form. I added a textbox. In the AfterUpdate event I have
the following code.
Private Sub Text2_AfterUpda te()
If IsNumeric(Me.Te xt2) Then
MsgBox "Numeric"
Else
MsgBox "Alpha"
End If
End Sub

I entered 1.2.2 and I got "Alpha". Which is correct.

There's a difference between using a form and entering data into an
immedicate window.

**Tom van Stiphout** · Jul 28 '08, 04:05 AM

Re: isnumeric compile error...

On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oil@vinegar.co mwrote:

Hi Salad,
I don't agree with your assertion "There's a difference between using
a form and entering data into an immedicate window" at least when it
comes to the performance of IsNumeric. Both environments use the same
VBA to do their job.

The reason isnumeric(1.2.2 ) fails whereas the other ones MLH mentions
succeed is that this one does not convert to a number or a string.
The help file says that IsNumeric takes a number or a string. 1.2.2 is
neither. That's why it fails.

-Tom.
Microsoft Access MVP

>MLH wrote:

>I have tested the following in immed window:
>>
>?isnumeric(1 )
>True
>?isnumeric(1 .)
>True
>?isnumeric(1.2 )
>True
>?isnumeric(1.2 .2)
>>
>The last one does not print True nor False.
>Instead, A97 complains of a compile error.
>I would really prefer False, should such be
>the case. What's the best way not to be
>bothered with the error and just assume
>False is returned?
>>
>Experimentin g with CStr was not fruitful
>because 1.2.2 is neither a valid numeric
>expression nor a valid string expression.

>
>Why is it not a valid string?
>

>So, what can I do if I find myself needing
>to process ?CStr(1.2.2) in the same way
>?CStr("1.2.2 ") would be processed.

>
>Put quotes around it. You're in debug, not a form or report or query or
>table.
>

>If a user enters 1.2.2 in an unbound text-
>box expecting a valid numeric entry, I
>would like very much to determine, in
>code, that it is NOT a valid numeric.
>But IsNumeric(1.2.2 ) is not the answer
>and neither is IsNumeric(CStr( 1.2.2)). So
>what do I do?

>
>I created a form. I added a textbox. In the AfterUpdate event I have
>the following code.
>Private Sub Text2_AfterUpda te()
If IsNumeric(Me.Te xt2) Then
MsgBox "Numeric"
Else
MsgBox "Alpha"
End If
>End Sub
>
>I entered 1.2.2 and I got "Alpha". Which is correct.
>
>There's a difference between using a form and entering data into an
>immedicate window.

**Salad** · Jul 28 '08, 04:35 AM

Re: isnumeric compile error...

Tom van Stiphout wrote:

On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oil@vinegar.co mwrote:
>
Hi Salad,
I don't agree with your assertion "There's a difference between using
a form and entering data into an immedicate window" at least when it
comes to the performance of IsNumeric. Both environments use the same
VBA to do their job.

I can enter 1.1.1 into a text box with no quotes and IsNumeric works
just find.

If I am in Debug, to enter 1.1.1 not in quotes is incorrect. Is isn't a
number, it's a string. It's the same as if I wrote
? Isnumeric(Hi Tom!)
I'd expect an error.

I doubt MLH would have gotten an error if he did this
var = "1.1.1"
? Isnumeric(var)

The reason I would get an accurate result using an unbound textbox in a
form is that Text0, in my opionion, is similar to a variable of type
variant.

>
The reason isnumeric(1.2.2 ) fails whereas the other ones MLH mentions
succeed is that this one does not convert to a number or a string.
The help file says that IsNumeric takes a number or a string. 1.2.2 is
neither. That's why it fails.

The only time I can see MLH's error occurring is if he's doing
everything from the debug/immediate window. To me, that is a data
entry, perhaps logic, error he made in the Debug window. IOW...user error.

The advice he was seeking, as far as I'm concerned, is how does he/she
write statements in the Debug window and what to do if the statement is
incorrect.

>
-Tom.
Microsoft Access MVP
>
>
>
>

>>MLH wrote:
>>

>>>I have tested the following in immed window:
>>>
>>>?isnumeric(1 )
>>>True
>>>?isnumeric(1 .)
>>>True
>>>?isnumeric(1 .2)
>>>True
>>>?isnumeric(1 .2.2)
>>>
>>>The last one does not print True nor False.
>>>Instead, A97 complains of a compile error.
>>>I would really prefer False, should such be
>>>the case. What's the best way not to be
>>>bothered with the error and just assume
>>>False is returned?
>>>
>>>Experimentin g with CStr was not fruitful
>>>because 1.2.2 is neither a valid numeric
>>>expression nor a valid string expression.

>>
>>Why is it not a valid string?
>>
>>

>>>So, what can I do if I find myself needing
>>>to process ?CStr(1.2.2) in the same way
>>>?CStr("1.2.2 ") would be processed.

>>
>>Put quotes around it. You're in debug, not a form or report or query or
>>table.
>>
>>

>>>If a user enters 1.2.2 in an unbound text-
>>>box expecting a valid numeric entry, I
>>>would like very much to determine, in
>>>code, that it is NOT a valid numeric.
>>>But IsNumeric(1.2.2 ) is not the answer
>>>and neither is IsNumeric(CStr( 1.2.2)). So
>>>what do I do?

>>
>>I created a form. I added a textbox. In the AfterUpdate event I have
>>the following code.
>>Private Sub Text2_AfterUpda te()
> If IsNumeric(Me.Te xt2) Then
> MsgBox "Numeric"
> Else
> MsgBox "Alpha"
> End If
>>End Sub
>>
>>I entered 1.2.2 and I got "Alpha". Which is correct.
>>
>>There's a difference between using a form and entering data into an
>>immedicate window.

**Tom van Stiphout** · Jul 28 '08, 04:45 AM

Re: isnumeric compile error...

On Sun, 27 Jul 2008 21:31:35 -0700, Salad <oil@vinegar.co mwrote:

>Tom van Stiphout wrote:

>On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oil@vinegar.co mwrote:
>>
>Hi Salad,
>I don't agree with your assertion "There's a difference between using
>a form and entering data into an immedicate window" at least when it
>comes to the performance of IsNumeric. Both environments use the same
>VBA to do their job.

>
>I can enter 1.1.1 into a text box with no quotes and IsNumeric works
>just find.
>
>If I am in Debug, to enter 1.1.1 not in quotes is incorrect. Is isn't a
>number, it's a string. It's the same as if I wrote
> ? Isnumeric(Hi Tom!)
>I'd expect an error.
>
>I doubt MLH would have gotten an error if he did this
> var = "1.1.1"
> ? Isnumeric(var)
>
>The reason I would get an accurate result using an unbound textbox in a
>form is that Text0, in my opionion, is similar to a variable of type
>variant.
>

>>
>The reason isnumeric(1.2.2 ) fails whereas the other ones MLH mentions
>succeed is that this one does not convert to a number or a string.
>The help file says that IsNumeric takes a number or a string. 1.2.2 is
>neither. That's why it fails.

>
>The only time I can see MLH's error occurring is if he's doing
>everything from the debug/immediate window. To me, that is a data
>entry, perhaps logic, error he made in the Debug window. IOW...user error.
>
>The advice he was seeking, as far as I'm concerned, is how does he/she
>write statements in the Debug window and what to do if the statement is
>incorrect.
>
>

>>
>-Tom.
>Microsoft Access MVP
>>
>>
>>
>>

>>>MLH wrote:
>>>
>>>>I have tested the following in immed window:
>>>>
>>>>?isnumeric( 1)
>>>>True
>>>>?isnumeric( 1.)
>>>>True
>>>>?isnumeric( 1.2)
>>>>True
>>>>?isnumeric( 1.2.2)
>>>>
>>>>The last one does not print True nor False.
>>>>Instead, A97 complains of a compile error.
>>>>I would really prefer False, should such be
>>>>the case. What's the best way not to be
>>>>bothered with the error and just assume
>>>>False is returned?
>>>>
>>>>Experimenti ng with CStr was not fruitful
>>>>because 1.2.2 is neither a valid numeric
>>>>expressio n nor a valid string expression.
>>>
>>>Why is it not a valid string?
>>>
>>>
>>>>So, what can I do if I find myself needing
>>>>to process ?CStr(1.2.2) in the same way
>>>>?CStr("1.2. 2") would be processed.
>>>
>>>Put quotes around it. You're in debug, not a form or report or query or
>>>table.
>>>
>>>
>>>>If a user enters 1.2.2 in an unbound text-
>>>>box expecting a valid numeric entry, I
>>>>would like very much to determine, in
>>>>code, that it is NOT a valid numeric.
>>>>But IsNumeric(1.2.2 ) is not the answer
>>>>and neither is IsNumeric(CStr( 1.2.2)). So
>>>>what do I do?
>>>
>>>I created a form. I added a textbox. In the AfterUpdate event I have
>>>the following code.
>>>Private Sub Text2_AfterUpda te()
>> If IsNumeric(Me.Te xt2) Then
>> MsgBox "Numeric"
>> Else
>> MsgBox "Alpha"
>> End If
>>>End Sub
>>>
>>>I entered 1.2.2 and I got "Alpha". Which is correct.
>>>
>>>There's a difference between using a form and entering data into an
>>>immedicate window.

**Tom van Stiphout** · Jul 28 '08, 05:05 AM

Re: isnumeric compile error...

On Sun, 27 Jul 2008 21:31:35 -0700, Salad <oil@vinegar.co mwrote:

Your first test I cannot confirm in A2007. If I have an unbound
textbox and an AfterUpdate event:
Private Sub Text47_AfterUpd ate()
Debug.Print Text47.value, IsNumeric(Text4 7)
End Sub

Then it will consistently print:
1.1.1 False
Indeed IsNumeric works fine (no error) and since

I agree that an unbound textbox with value of 1.1.1 will run IsNumeric
just fine and it will return False. I agree we can think of this value
to be of type Variant, but if you test it using VarType, you will find
it is of type String.

I disagree when you say "If I am in Debug, to enter 1.1.1 not in
quotes is incorrect. Is isn't a number, it's a string"
I would argue: no it's not. It's an illegal value. Strings are wrapped
with "".

Isnumeric(Hi Tom!)
is also syntactically incorrect for the same reason.
Isnumeric("Hi Tom!")
is the correct syntax.

Assuming var is a Variant, there would not be an error, but just a
return value of False for var="1.1.1".

-Tom.

>Tom van Stiphout wrote:

>On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oil@vinegar.co mwrote:
>>
>Hi Salad,
>I don't agree with your assertion "There's a difference between using
>a form and entering data into an immedicate window" at least when it
>comes to the performance of IsNumeric. Both environments use the same
>VBA to do their job.

>
>I can enter 1.1.1 into a text box with no quotes and IsNumeric works
>just find.
>
>If I am in Debug, to enter 1.1.1 not in quotes is incorrect. Is isn't a
>number, it's a string. It's the same as if I wrote
> ? Isnumeric(Hi Tom!)
>I'd expect an error.
>
>I doubt MLH would have gotten an error if he did this
> var = "1.1.1"
> ? Isnumeric(var)
>
>The reason I would get an accurate result using an unbound textbox in a
>form is that Text0, in my opionion, is similar to a variable of type
>variant.
>

>>
>The reason isnumeric(1.2.2 ) fails whereas the other ones MLH mentions
>succeed is that this one does not convert to a number or a string.
>The help file says that IsNumeric takes a number or a string. 1.2.2 is
>neither. That's why it fails.

>
>The only time I can see MLH's error occurring is if he's doing
>everything from the debug/immediate window. To me, that is a data
>entry, perhaps logic, error he made in the Debug window. IOW...user error.
>
>The advice he was seeking, as far as I'm concerned, is how does he/she
>write statements in the Debug window and what to do if the statement is
>incorrect.
>
>

>>
>-Tom.
>Microsoft Access MVP
>>
>>
>>
>>

>>>MLH wrote:
>>>
>>>>I have tested the following in immed window:
>>>>
>>>>?isnumeric( 1)
>>>>True
>>>>?isnumeric( 1.)
>>>>True
>>>>?isnumeric( 1.2)
>>>>True
>>>>?isnumeric( 1.2.2)
>>>>
>>>>The last one does not print True nor False.
>>>>Instead, A97 complains of a compile error.
>>>>I would really prefer False, should such be
>>>>the case. What's the best way not to be
>>>>bothered with the error and just assume
>>>>False is returned?
>>>>
>>>>Experimenti ng with CStr was not fruitful
>>>>because 1.2.2 is neither a valid numeric
>>>>expressio n nor a valid string expression.
>>>
>>>Why is it not a valid string?
>>>
>>>
>>>>So, what can I do if I find myself needing
>>>>to process ?CStr(1.2.2) in the same way
>>>>?CStr("1.2. 2") would be processed.
>>>
>>>Put quotes around it. You're in debug, not a form or report or query or
>>>table.
>>>
>>>
>>>>If a user enters 1.2.2 in an unbound text-
>>>>box expecting a valid numeric entry, I
>>>>would like very much to determine, in
>>>>code, that it is NOT a valid numeric.
>>>>But IsNumeric(1.2.2 ) is not the answer
>>>>and neither is IsNumeric(CStr( 1.2.2)). So
>>>>what do I do?
>>>
>>>I created a form. I added a textbox. In the AfterUpdate event I have
>>>the following code.
>>>Private Sub Text2_AfterUpda te()
>> If IsNumeric(Me.Te xt2) Then
>> MsgBox "Numeric"
>> Else
>> MsgBox "Alpha"
>> End If
>>>End Sub
>>>
>>>I entered 1.2.2 and I got "Alpha". Which is correct.
>>>
>>>There's a difference between using a form and entering data into an
>>>immedicate window.

**MLH** · Jul 28 '08, 02:05 PM

Re: isnumeric compile error...

On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oil@vinegar.co mwrote:

>MLH wrote:

>I have tested the following in immed window:
>>
>?isnumeric(1 )
>True
>?isnumeric(1 .)
>True
>?isnumeric(1.2 )
>True
>?isnumeric(1.2 .2)
>>
>The last one does not print True nor False.
>Instead, A97 complains of a compile error.
>I would really prefer False, should such be
>the case. What's the best way not to be
>bothered with the error and just assume
>False is returned?
>>
>Experimentin g with CStr was not fruitful
>because 1.2.2 is neither a valid numeric
>expression nor a valid string expression.

>
>Why is it not a valid string?
>

>So, what can I do if I find myself needing
>to process ?CStr(1.2.2) in the same way
>?CStr("1.2.2 ") would be processed.

>
>Put quotes around it. You're in debug, not a form or report or query or
>table.
>

>If a user enters 1.2.2 in an unbound text-
>box expecting a valid numeric entry, I
>would like very much to determine, in
>code, that it is NOT a valid numeric.
>But IsNumeric(1.2.2 ) is not the answer
>and neither is IsNumeric(CStr( 1.2.2)). So
>what do I do?

>
>I created a form. I added a textbox. In the AfterUpdate event I have
>the following code.
>Private Sub Text2_AfterUpda te()
If IsNumeric(Me.Te xt2) Then
MsgBox "Numeric"
Else
MsgBox "Alpha"
End If
>End Sub
>
>I entered 1.2.2 and I got "Alpha". Which is correct.
>
>There's a difference between using a form and entering data into an
>immedicate window.

I'd noticed that. But I considered it a glitch! I had no
clue. Why would the Access developers do such a
thing? I mean, the PURPOSE of the Debug Window
the former Immediate Window, I thought, was to test
crap you were gonna use in code! Are there any other
sneaky gotchas like that running around???

**MLH** · Jul 28 '08, 02:25 PM

Re: isnumeric compile error...

I'm not the sharpest tool in the shed, but it
sure seems like Salad has a point.

If I've got Text0 and Text2 textboxes on an
otherwise empty form and Text0 has this AfterUpdate
event property ...

Private Sub Text0_AfterUpda te()
If IsNumeric(Text0 ) Then Text2 = True Else Text2 = False
End Sub

.... I don't get a compile error typing ANY of the following
into Text0 ...

1
1.
1.2
1.2.2
"1.2.2"

.... and pressing ENTER. I get either True or False
(first 3 True, last 2 False). That's certainly a different
than the debug window provides. If the debug window
is using the same VBA that running Access procedures
use = then it's sending different arguments or using a
different part of VBA than procedures in forms are
using. I mean, if you throw the same salad ingrediens
into 2 different black boxes and one spits out a salad
and the other a pizza - well, U-C what I'm saying.

**MLH** · Jul 28 '08, 02:45 PM

Re: isnumeric compile error...

Addiing to your point,

?isnumeric(abcd e)
True

in the immediate window.

But on a form in a textbox it yields False.
Of course, in the form's textbox, abcde
is being viewed as data. And in debug,
well, it's not readily apparent ...

?abcde

?VarType(abcde)
0 (empty, unitialized)

.... which is not the same as vbVariant (12).
So, I don't think there's enough substance
here to base an argument on in either direction.
I don't think what's happening is something
that was carefully planned or intended - or
even addressed for that matter. I think it's a
screw-up & the ADT overlooked it altogether.

**Salad** · Jul 28 '08, 02:55 PM

Re: isnumeric compile error...

MLH wrote:

On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oil@vinegar.co mwrote:
>
>

>>MLH wrote:
>>

>>>I have tested the following in immed window:
>>>
>>>?isnumeric(1 )
>>>True
>>>?isnumeric(1 .)
>>>True
>>>?isnumeric(1 .2)
>>>True
>>>?isnumeric(1 .2.2)
>>>
>>>The last one does not print True nor False.
>>>Instead, A97 complains of a compile error.
>>>I would really prefer False, should such be
>>>the case. What's the best way not to be
>>>bothered with the error and just assume
>>>False is returned?
>>>
>>>Experimentin g with CStr was not fruitful
>>>because 1.2.2 is neither a valid numeric
>>>expression nor a valid string expression.

>>
>>Why is it not a valid string?
>>
>>

>>>So, what can I do if I find myself needing
>>>to process ?CStr(1.2.2) in the same way
>>>?CStr("1.2.2 ") would be processed.

>>
>>Put quotes around it. You're in debug, not a form or report or query or
>>table.
>>
>>

>>>If a user enters 1.2.2 in an unbound text-
>>>box expecting a valid numeric entry, I
>>>would like very much to determine, in
>>>code, that it is NOT a valid numeric.
>>>But IsNumeric(1.2.2 ) is not the answer
>>>and neither is IsNumeric(CStr( 1.2.2)). So
>>>what do I do?

>>
>>I created a form. I added a textbox. In the AfterUpdate event I have
>>the following code.
>>Private Sub Text2_AfterUpda te()
> If IsNumeric(Me.Te xt2) Then
> MsgBox "Numeric"
> Else
> MsgBox "Alpha"
> End If
>>End Sub
>>
>>I entered 1.2.2 and I got "Alpha". Which is correct.
>>
>>There's a difference between using a form and entering data into an
>>immedicate window.

>
>
I'd noticed that. But I considered it a glitch! I had no
clue. Why would the Access developers do such a
thing? I mean, the PURPOSE of the Debug Window
the former Immediate Window, I thought, was to test
crap you were gonna use in code! Are there any other
sneaky gotchas like that running around???

If I input incorrect data into the immediate window I'd expect an error.
Garbage in, garbage out. You entered in garbage and expected Access
to fix it.

You were using a literal value that was incorrectly entered. Then you
complain about Access noting the error. Why?

**Salad** · Jul 28 '08, 03:05 PM

Re: isnumeric compile error...

MLH wrote:

I'm not the sharpest tool in the shed, but it
sure seems like Salad has a point.
>
If I've got Text0 and Text2 textboxes on an
otherwise empty form and Text0 has this AfterUpdate
event property ...
>
Private Sub Text0_AfterUpda te()
If IsNumeric(Text0 ) Then Text2 = True Else Text2 = False
End Sub
>
... I don't get a compile error typing ANY of the following
into Text0 ...
>
1
1.
1.2
1.2.2
"1.2.2"
>
... and pressing ENTER. I get either True or False
(first 3 True, last 2 False). That's certainly a different
than the debug window provides. If the debug window
is using the same VBA that running Access procedures
use = then it's sending different arguments or using a
different part of VBA than procedures in forms are
using. I mean, if you throw the same salad ingrediens
into 2 different black boxes and one spits out a salad
and the other a pizza - well, U-C what I'm saying.

Although Text0 isn't a variable...cons ider it as one. A variable is
different from a literal. You entered a literal in the debug window.

For an experiment, try this from the debug window.
var = 1.1.2
Did you get an error? I did. Ok, let me fix it.
var = "1.1.2"
No error this time. Now I'll expand
? IsNumeric(var)
No error. And the result is false. Since you started with a data entry
error of course you are going to get an error doing
? IsNumerica(1.1. 2)
Entering
? IsNumeric(Hi MLH)
is similar to
? IsNumeric(1.1.2 )
because both are entered incorrectly.

**Salad** · Jul 28 '08, 03:05 PM

Re: isnumeric compile error...

MLH wrote:

Addiing to your point,
>
?isnumeric(abcd e)
True
>
in the immediate window.
>
But on a form in a textbox it yields False.
Of course, in the form's textbox, abcde
is being viewed as data. And in debug,
well, it's not readily apparent ...
>
?abcde
>
?VarType(abcde)
0 (empty, unitialized)
>
... which is not the same as vbVariant (12).
So, I don't think there's enough substance
here to base an argument on in either direction.
I don't think what's happening is something
that was carefully planned or intended - or
even addressed for that matter. I think it's a
screw-up & the ADT overlooked it altogether.

When you can show me that garbage in doesn't result in garbage out you
will convince me, and millions of programmers world wide, that a miracle
has taken place. Praise Jesus!

**paii, Ron** · Jul 28 '08, 05:45 PM

Re: isnumeric compile error...

"MLH" <CRCI@NorthStat e.netwrote in message
news:d0kr84hf74 56omkqr1t9mav07 duvsopm95@4ax.c om...

On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oil@vinegar.co mwrote:
>

MLH wrote:

I have tested the following in immed window:
>
?isnumeric(1)
True
?isnumeric(1.)
True
?isnumeric(1.2)
True
?isnumeric(1.2. 2)
>
The last one does not print True nor False.
Instead, A97 complains of a compile error.
I would really prefer False, should such be
the case. What's the best way not to be
bothered with the error and just assume
False is returned?
>
Experimenting with CStr was not fruitful
because 1.2.2 is neither a valid numeric
expression nor a valid string expression.

Why is it not a valid string?

So, what can I do if I find myself needing
to process ?CStr(1.2.2) in the same way
?CStr("1.2.2") would be processed.

Put quotes around it. You're in debug, not a form or report or query or
table.

If a user enters 1.2.2 in an unbound text-
box expecting a valid numeric entry, I
would like very much to determine, in
code, that it is NOT a valid numeric.
But IsNumeric(1.2.2 ) is not the answer
and neither is IsNumeric(CStr( 1.2.2)). So
what do I do?

I created a form. I added a textbox. In the AfterUpdate event I have
the following code.
Private Sub Text2_AfterUpda te()
If IsNumeric(Me.Te xt2) Then
MsgBox "Numeric"
Else
MsgBox "Alpha"
End If
End Sub

I entered 1.2.2 and I got "Alpha". Which is correct.

There's a difference between using a form and entering data into an
immedicate window.

>
I'd noticed that. But I considered it a glitch! I had no
clue. Why would the Access developers do such a
thing? I mean, the PURPOSE of the Debug Window
the former Immediate Window, I thought, was to test
crap you were gonna use in code! Are there any other
sneaky gotchas like that running around???

Add the following lines to a function and try to compile, you will get an
error just like in the immediate window. So where is the glitch?

If IsNumeric(1.2.2 ) Then
End If

**MLH** · Aug 9 '08, 08:35 PM

Re: isnumeric compile error...

<snip>

>
>When you can show me that garbage in doesn't result in garbage out you
>will convince me, and millions of programmers world wide, that a miracle
>has taken place. Praise Jesus!

Point well taken. But I'm talking about users here - not programmers.
I was hoping that as a programmer, I might be able to capture a data
entry error made by a user and recover from it gracefully.

**MLH** · Aug 9 '08, 08:35 PM

Re: isnumeric compile error...

<Snip>

>If I input incorrect data into the immediate window I'd expect an error.
Garbage in, garbage out. You entered in garbage and expected Access
>to fix it.
>
>You were using a literal value that was incorrectly entered. Then you
>complain about Access noting the error. Why?

Again, point well taken. So, some program code dynamics are difficult
to replicate in the debug window. Any recommendations as to how one
might gracefully skirt around a user data entry error of 1.1.1 into a
textbox control expecting a valid numeric entry?

isnumeric compile error...

isnumeric compile error...

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment