By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,335 Members | 2,281 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,335 IT Pros & Developers. It's quick & easy.

isnumeric compile error...

P: n/a
MLH
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.
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.

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?
Jul 28 '08 #1
Share this Question
Share on Google+
17 Replies


P: n/a
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_AfterUpdate()
If IsNumeric(Me.Text2) 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.
Jul 28 '08 #2

P: n/a
On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oi*@vinegar.comwrote:

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?

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_AfterUpdate()
If IsNumeric(Me.Text2) 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.
Jul 28 '08 #3

P: n/a
Tom van Stiphout wrote:
On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oi*@vinegar.comwrote:

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?

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_AfterUpdate()
If IsNumeric(Me.Text2) 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.
Jul 28 '08 #4

P: n/a
On Sun, 27 Jul 2008 21:31:35 -0700, Salad <oi*@vinegar.comwrote:
>Tom van Stiphout wrote:
>On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oi*@vinegar.comwrote:

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?

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_AfterUpdate()
If IsNumeric(Me.Text2) 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.
Jul 28 '08 #5

P: n/a
On Sun, 27 Jul 2008 21:31:35 -0700, Salad <oi*@vinegar.comwrote:

Your first test I cannot confirm in A2007. If I have an unbound
textbox and an AfterUpdate event:
Private Sub Text47_AfterUpdate()
Debug.Print Text47.value, IsNumeric(Text47)
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 <oi*@vinegar.comwrote:

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?

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_AfterUpdate()
If IsNumeric(Me.Text2) 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.
Jul 28 '08 #6

P: n/a
MLH
On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oi*@vinegar.comwrote:
>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_AfterUpdate()
If IsNumeric(Me.Text2) 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???
Jul 28 '08 #7

P: n/a
MLH
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_AfterUpdate()
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.
Jul 28 '08 #8

P: n/a
MLH
Addiing to your point,

?isnumeric(abcde)
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.
Jul 28 '08 #9

P: n/a
MLH wrote:
On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oi*@vinegar.comwrote:

>>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_AfterUpdate()
If IsNumeric(Me.Text2) 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?

Jul 28 '08 #10

P: n/a
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_AfterUpdate()
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...consider 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.


Jul 28 '08 #11

P: n/a
MLH wrote:
Addiing to your point,

?isnumeric(abcde)
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!

Jul 28 '08 #12

P: n/a

"MLH" <CR**@NorthState.netwrote in message
news:d0********************************@4ax.com...
On Sun, 27 Jul 2008 19:50:17 -0700, Salad <oi*@vinegar.comwrote:
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_AfterUpdate()
If IsNumeric(Me.Text2) 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

Jul 28 '08 #13

P: n/a
MLH
<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.

Aug 9 '08 #14

P: n/a
MLH
<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?
Aug 9 '08 #15

P: n/a
MLH wrote:
<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?
Yes, check for it's validity in the BeforeUpdate event.

Entering IsNumeric(1.1.2) in Debug is different than entering 1.2.2 in a
textbox. One is a literal, the other what I'd consider a variable. If
bound to a numeric field you would get an error.

If you are running all your functions and subs from debug then you need
to enter in data correctly.

Aug 10 '08 #16

P: n/a
MLH
<snip>
>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

What you say is True. I didn't try that. Salad pointed out that
literals are processed differently than variables. It all makes
sense now. Thanks.
Aug 10 '08 #17

P: n/a
MLH
Thx, Salad. Makes perfect sense. The difference
is clear. Somehow, it just went over my head.
Aug 10 '08 #18

This discussion thread is closed

Replies have been disabled for this discussion.