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?
17  2252 
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.
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.
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.
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.
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.
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???
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.
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.
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?
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.
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!
"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
<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.
<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?
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.
<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.
Thx, Salad. Makes perfect sense. The difference
is clear. Somehow, it just went over my head.
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: DCM Fan |
last post by:
SELECT ISNUMERIC('. ')
1
SELECT CAST('. ' AS )
Syntax error converting the varchar value '. ' to a column of data type
.
Any thoughts as to why SQL Server 7.0 considers '. ' to be...
|
by: eje |
last post by:
IsNumeric(value) should return false if value "can not be
successfully converted to a Double." Instead I get the
following error message: "Input string was not in a
correct format."
I use the...
|
by: Eugene Anthony |
last post by:
I have received the following feedback for the two functions bellow:
"The ISNUMERIC test is WORTHLESS for checking for an INT value, because
ISNUMERIC will happily accept DOUBLE values, such as...
|
by: Kenny |
last post by:
Hello,
I would like to know if the function IsNumeric requires a header like
#include <iostream> to be functionnal
thanks
ken
|
by: crowl |
last post by:
I have a pocket pc project in c#.
From a textbox i have to verify if the input is numeric. I have found
in the msdn a sample like this: textbox1.numeric = true / false. But
this do not work in...
|
by: martin |
last post by:
Hi,
is there a dotnet function (other than the old isnumeric from VB) to check
whether an object is numeric or not.
also I notice that all the old vb functions such as split / isnumeric /...
|
by: Radith Silva |
last post by:
Dear All;
Thanx for helpt with previous question. Still learning??
FROM A VB 6.0 BOOK:
any way;
I have used IsNumeric function and check all namespace conflicts and all
and nothing seems...
|
by: michele |
last post by:
I have a problem with VB.Net and IsNumeric() function because it always
returns FALSE even the string can be a number.
There is another strange thing, the same program (it is a test) runs good on...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| |
