Convert text string to number? 
Author Message
 Convert text string to number?

How do I take a text box value and convert it to a number?

ie.

txtTest.text = "99"

I have tried

CInt (txtText.text)
 but I keep getting a type mismatch error

Mark



Sat, 15 Jan 2005 23:46:49 GMT  
 Convert text string to number?
Sounds like you're trying to convert it when it's blank.  CInt("99") will
work, but CInt("") won't.  You could do a couple things, like check for a
numeric value before coercing, or append a "0" to the beginning of the
string.

-Chris


Quote:
> How do I take a text box value and convert it to a number?

> ie.

> txtTest.text = "99"

> I have tried

> CInt (txtText.text)
>  but I keep getting a type mismatch error

> Mark



Sat, 15 Jan 2005 23:51:05 GMT  
 Convert text string to number?


Quote:
> Sounds like you're trying to convert it when it's blank.  CInt("99") will
> work, but CInt("") won't.  You could do a couple things, like check for a
> numeric value before coercing, or append a "0" to the beginning of the
> string.

Sound advice, but I would add an on error statement as well to catch the
times where either the text field is empty or contains illegal data (alfa
chars or spaces).

Keld Laursen



Sun, 16 Jan 2005 15:04:18 GMT  
 Convert text string to number?
To ensure that you only get a number, and force an error if it's not a
number or if it's blank, you can use

A = 0 + txtTest.text


Quote:
> How do I take a text box value and convert it to a number?

> ie.

> txtTest.text = "99"

> I have tried

> CInt (txtText.text)
>  but I keep getting a type mismatch error

> Mark



Sun, 16 Jan 2005 18:19:52 GMT  
 Convert text string to number?
THis is bad practive - adding a number to a string an hoping the variant
rules will handle it.  It would be more correct to do this:

A = CInt("0" & txtTest.Text)

And as Keld said, you may want to check for valid data first, because
character data could be a problem.

--
Chris Tacke, eMVP
Windows CE Product Manager
Applied Data Systems
www.applieddata.net


Quote:
> To ensure that you only get a number, and force an error if it's not a
> number or if it's blank, you can use

> A = 0 + txtTest.text



> > How do I take a text box value and convert it to a number?

> > ie.

> > txtTest.text = "99"

> > I have tried

> > CInt (txtText.text)
> >  but I keep getting a type mismatch error

> > Mark



Sun, 16 Jan 2005 21:14:56 GMT  
 Convert text string to number?
How about

If IsNumeric(txtTest.Text) then
    intVar = CInt(txtTest.Text)
Else
    MsgBox "Not a number!"
    'do something to initialize your var for this case,
    'e.g. intVar = -1 or so
End If

HTH,
Mike


Quote:
> How do I take a text box value and convert it to a number?

> ie.

> txtTest.text = "99"

> I have tried

> CInt (txtText.text)
>  but I keep getting a type mismatch error

> Mark



Sun, 16 Jan 2005 21:47:52 GMT  
 Convert text string to number?
What string?  txtTest.Text is a variant.

The addition generates a trappable error if it can't be done.



Quote:
> THis is bad practive - adding a number to a string an hoping the variant
> rules will handle it.  It would be more correct to do this:

> A = CInt("0" & txtTest.Text)

> And as Keld said, you may want to check for valid data first, because
> character data could be a problem.



Mon, 17 Jan 2005 09:34:42 GMT  
 Convert text string to number?

Quote:
> What string?  txtTest.Text is a variant.

> The addition generates a trappable error if it can't be done.

Any wrong doing generates a trappable error!
One error that your version doesn't catch is the "field empty" error.
It might not always be desirable to read this as a 0 value.

Once upon a time, I did some ASP programming, and I had to coerce the data
into being integers by adding 0 to them, but I can't remember why I ended up
with that construct. I'm sure I also tried cint() on the data.

I would probably put something like this code into the OnChange event of the
editbox:

    On Error Resume Next
        Err.Number = 0
        MyIntVar = cInt(MyEditBox.Text)
        If Err.Number Then
            '... do whatever is desired here ...
        End If
    On Error Goto 0

Always remember to turn off error handling again. It will be turned off
automatically when returning from a sub or function, but it is very good
practice to do it yourself as well.
In fact, one ought to turn off error trapping inside the error processing
code, like:

    On Error Resume Next
        Err.Number = 0
        MyIntVar = cInt(MyEditBox.Text)
        If Err.Number Then
            on error goto 0
            '... do whatever is desired here ...
        End If
    On Error Goto 0

Best regards,

Keld Laursen



Mon, 17 Jan 2005 14:16:09 GMT  
 Convert text string to number?
I don't know what your criteria for good or bad practive is, but there's
nothing wrong with an espresso such as the one I suggested. CInt is a
numeric function - it is not a 'make number from string' function.  It
requires a numeric argument in exactly the same way that the + operator
does, so exactly the same coercion from variant to numeric is occurring in
both cases. Both procedures are 'relying' on the variant rules to provide
the numeric format of the text that was entered by the user. _Any_ numeric
usage of a variant, whether it's part of a numeric operation or as an
argument to a numeric function, relies on these rules in exactly the same
way, and I can't see any reason for concern about that.

If you want the additional functionality that CInt provides then by all
means use it, but if you want whatever the user typed, in so far as it can
be a number, then use my simpler version.  If it can't be made into a number
an error is generated (as I mentioned) and the error can be trapped - there
is no need for prior testing.



Quote:
> THis is bad practive - adding a number to a string an hoping the variant
> rules will handle it.  It would be more correct to do this:

> A = CInt("0" & txtTest.Text)

> And as Keld said, you may want to check for valid data first, because
> character data could be a problem.



Mon, 17 Jan 2005 16:48:01 GMT  
 Convert text string to number?
You must be using a different version, because on my machine the addition of
zero generates an error when the user leaves the field empty, exactly the
same as CInt() does.


Quote:
> snip <

> Any wrong doing generates a trappable error!
> One error that your version doesn't catch is the "field empty" error.
> It might not always be desirable to read this as a 0 value.

> Once upon a time, I did some ASP programming, and I had to coerce the data
> into being integers by adding 0 to them, but I can't remember why I ended
up
> with that construct. I'm sure I also tried cint() on the data.

> I would probably put something like this code into the OnChange event of
the
> editbox:

>     On Error Resume Next
>         Err.Number = 0
>         MyIntVar = cInt(MyEditBox.Text)
>         If Err.Number Then
>             '... do whatever is desired here ...
>         End If
>     On Error Goto 0

> Always remember to turn off error handling again. It will be turned off
> automatically when returning from a sub or function, but it is very good
> practice to do it yourself as well.
> In fact, one ought to turn off error trapping inside the error processing
> code, like:

>     On Error Resume Next
>         Err.Number = 0
>         MyIntVar = cInt(MyEditBox.Text)
>         If Err.Number Then
>             on error goto 0
>             '... do whatever is desired here ...
>         End If
>     On Error Goto 0

> Best regards,

> Keld Laursen



Mon, 17 Jan 2005 16:56:57 GMT  
 Convert text string to number?
Way too complex.  There is no need for separate testing. The assignment does
not occur if an error is raised, so the variable can be initialized to the
error result. This code does exactly the same job.

intVar = -1 (or whatever)
On Error Resume Next
intVar = 0 + txtTest.Text
If Err.Number then MsgBox "Not a number"
On Error Goto 0


Quote:
> How about

> If IsNumeric(txtTest.Text) then
>     intVar = CInt(txtTest.Text)
> Else
>     MsgBox "Not a number!"
>     'do something to initialize your var for this case,
>     'e.g. intVar = -1 or so
> End If



Tue, 18 Jan 2005 06:50:09 GMT  
 Convert text string to number?
Hi,

I don't think that CInt does need a numeric data type.  You can put anything
into it as long as its a numerical expression.

However, I think that what Chris Tacke was referring to, is that in using
your method, VB has to be clever and guess what type of variable it should
convert the textbox.text value into.  It is often recommended that VB coders
specify explicitly what type of conversion they want.  This has three
advantages:

1) It increases reliability.  If VB makes a wrong guess then it could cause
overflow errors, etc. later on.
2) It increases VB's ability to type check during compile, making debugging
much easier
3) It makes it easier for other coders to understand what you are wanting to
do if they have to ammend your code

Strangely enough, I read somewhere that explicitly specifying a value using
conversion factors such as CInt() would actually work faster than not
specifying.  But when I've just tried it, I've found it to be slower.  Any
ideas why?

Cheers,

Jamie.

--
Regards,

Jamie Brown, Development Manager
InfoComp Ltd

URL: http://www.infocomp.co.uk

Quote:
> I don't know what your criteria for good or bad practive is, but there's
> nothing wrong with an espresso such as the one I suggested. CInt is a
> numeric function - it is not a 'make number from string' function.  It
> requires a numeric argument in exactly the same way that the + operator
> does, so exactly the same coercion from variant to numeric is occurring in
> both cases. Both procedures are 'relying' on the variant rules to provide
> the numeric format of the text that was entered by the user. _Any_ numeric
> usage of a variant, whether it's part of a numeric operation or as an
> argument to a numeric function, relies on these rules in exactly the same
> way, and I can't see any reason for concern about that.

> If you want the additional functionality that CInt provides then by all
> means use it, but if you want whatever the user typed, in so far as it can
> be a number, then use my simpler version.  If it can't be made into a
number
> an error is generated (as I mentioned) and the error can be trapped -
there
> is no need for prior testing.



> > THis is bad practive - adding a number to a string an hoping the variant
> > rules will handle it.  It would be more correct to do this:

> > A = CInt("0" & txtTest.Text)

> > And as Keld said, you may want to check for valid data first, because
> > character data could be a problem.



Fri, 11 Feb 2005 19:22:13 GMT  
 Convert text string to number?
CInt does need a numeric argument - the function returns the integer part of
a number.   However, eVB only supports the variant type, so it's not
possible to explicitly pass a numeric argument to the function - all you can
pass is a variant, and a variant can contain anything at all.  txtTest.Text
is a variant.  The interpreter is responsible for turning that variant into
a number, as best it can, before evaluating CInt.  If the variant can't be
turned into a number, an error is returned.  In this case, CInt isn't even
invoked.

This testing and conversion of the variant data type is exactly the same as
occurs in the evaluation of any numeric expression. That's why there is no
functional difference in the testing for numeric that occurs in
"CInt(Variant)" or "0 + variant".  There is no difference between the two
approaches in terms of 'relying' on the testing of the variant to see if it
can be made a number or not.  And if it can be made a number, passing it
through the CInt function adds nothing to the process - CInt will not
discover any 'non-numeric' because it can never be passed a non-numeric
argument.

Therefore, your point 1 doesn't apply.

eVB does no type checking during compile, so your point 2 doesn't apply
(would that it did!).

Your point 3 could be debated for a long time. My expression can be used in
the same form wherever a test for a legal numeric is required. The CInt does
a test, but also converts to integer, which wouldn't always be appropriate -
sometimes single or double would be required.  So my form wins for
consistency, and in my experience consistency is very significant in
assisting others to understand the code. Of course, if we had a Val()
function I would happily vote for that on the grounds of transparency and
consistency, but we don't.

There are all sorts of other reasons for preferring one form over another,
but I do not accept that there is any technical basis for the decision about
which to choose.
--
Jeff Richards


Quote:
> Hi,

> I don't think that CInt does need a numeric data type.  You can put
anything
> into it as long as its a numerical expression.

> However, I think that what Chris Tacke was referring to, is that in using
> your method, VB has to be clever and guess what type of variable it should
> convert the textbox.text value into.  It is often recommended that VB
coders
> specify explicitly what type of conversion they want.  This has three
> advantages:

> 1) It increases reliability.  If VB makes a wrong guess then it could
cause
> overflow errors, etc. later on.
> 2) It increases VB's ability to type check during compile, making
debugging
> much easier
> 3) It makes it easier for other coders to understand what you are wanting
to
> do if they have to ammend your code

> Strangely enough, I read somewhere that explicitly specifying a value
using
> conversion factors such as CInt() would actually work faster than not
> specifying.  But when I've just tried it, I've found it to be slower.  Any
> ideas why?

> Cheers,

> Jamie.

> --
> Regards,

> Jamie Brown, Development Manager
> InfoComp Ltd

> URL: http://www.infocomp.co.uk


> > I don't know what your criteria for good or bad practive is, but there's
> > nothing wrong with an espresso such as the one I suggested. CInt is a
> > numeric function - it is not a 'make number from string' function.  It
> > requires a numeric argument in exactly the same way that the + operator
> > does, so exactly the same coercion from variant to numeric is occurring
in
> > both cases. Both procedures are 'relying' on the variant rules to
provide
> > the numeric format of the text that was entered by the user. _Any_
numeric
> > usage of a variant, whether it's part of a numeric operation or as an
> > argument to a numeric function, relies on these rules in exactly the
same
> > way, and I can't see any reason for concern about that.

> > If you want the additional functionality that CInt provides then by all
> > means use it, but if you want whatever the user typed, in so far as it
can
> > be a number, then use my simpler version.  If it can't be made into a
> number
> > an error is generated (as I mentioned) and the error can be trapped -
> there
> > is no need for prior testing.



> > > THis is bad practive - adding a number to a string an hoping the
variant
> > > rules will handle it.  It would be more correct to do this:

> > > A = CInt("0" & txtTest.Text)

> > > And as Keld said, you may want to check for valid data first, because
> > > character data could be a problem.



Sun, 13 Feb 2005 19:19:57 GMT  
 Convert text string to number?
Hi,

I've had a look through my VB help file and you were correct.  Appologies
for the error and thanks for the correction.

--
Regards,

Jamie Brown, Development Manager
InfoComp Ltd

URL: http://www.infocomp.co.uk


Quote:
> CInt does need a numeric argument - the function returns the integer part
of
> a number.   However, eVB only supports the variant type, so it's not
> possible to explicitly pass a numeric argument to the function - all you
can
> pass is a variant, and a variant can contain anything at all.
txtTest.Text
> is a variant.  The interpreter is responsible for turning that variant
into
> a number, as best it can, before evaluating CInt.  If the variant can't be
> turned into a number, an error is returned.  In this case, CInt isn't even
> invoked.

> This testing and conversion of the variant data type is exactly the same
as
> occurs in the evaluation of any numeric expression. That's why there is no
> functional difference in the testing for numeric that occurs in
> "CInt(Variant)" or "0 + variant".  There is no difference between the two
> approaches in terms of 'relying' on the testing of the variant to see if
it
> can be made a number or not.  And if it can be made a number, passing it
> through the CInt function adds nothing to the process - CInt will not
> discover any 'non-numeric' because it can never be passed a non-numeric
> argument.

> Therefore, your point 1 doesn't apply.

> eVB does no type checking during compile, so your point 2 doesn't apply
> (would that it did!).

> Your point 3 could be debated for a long time. My expression can be used
in
> the same form wherever a test for a legal numeric is required. The CInt
does
> a test, but also converts to integer, which wouldn't always be
appropriate -
> sometimes single or double would be required.  So my form wins for
> consistency, and in my experience consistency is very significant in
> assisting others to understand the code. Of course, if we had a Val()
> function I would happily vote for that on the grounds of transparency and
> consistency, but we don't.

> There are all sorts of other reasons for preferring one form over another,
> but I do not accept that there is any technical basis for the decision
about
> which to choose.
> --
> Jeff Richards



> > Hi,

> > I don't think that CInt does need a numeric data type.  You can put
> anything
> > into it as long as its a numerical expression.

> > However, I think that what Chris Tacke was referring to, is that in
using
> > your method, VB has to be clever and guess what type of variable it
should
> > convert the textbox.text value into.  It is often recommended that VB
> coders
> > specify explicitly what type of conversion they want.  This has three
> > advantages:

> > 1) It increases reliability.  If VB makes a wrong guess then it could
> cause
> > overflow errors, etc. later on.
> > 2) It increases VB's ability to type check during compile, making
> debugging
> > much easier
> > 3) It makes it easier for other coders to understand what you are
wanting
> to
> > do if they have to ammend your code

> > Strangely enough, I read somewhere that explicitly specifying a value
> using
> > conversion factors such as CInt() would actually work faster than not
> > specifying.  But when I've just tried it, I've found it to be slower.
Any
> > ideas why?

> > Cheers,

> > Jamie.

> > --
> > Regards,

> > Jamie Brown, Development Manager
> > InfoComp Ltd

> > URL: http://www.infocomp.co.uk


> > > I don't know what your criteria for good or bad practive is, but
there's
> > > nothing wrong with an espresso such as the one I suggested. CInt is a
> > > numeric function - it is not a 'make number from string' function.  It
> > > requires a numeric argument in exactly the same way that the +
operator
> > > does, so exactly the same coercion from variant to numeric is
occurring
> in
> > > both cases. Both procedures are 'relying' on the variant rules to
> provide
> > > the numeric format of the text that was entered by the user. _Any_
> numeric
> > > usage of a variant, whether it's part of a numeric operation or as an
> > > argument to a numeric function, relies on these rules in exactly the
> same
> > > way, and I can't see any reason for concern about that.

> > > If you want the additional functionality that CInt provides then by
all
> > > means use it, but if you want whatever the user typed, in so far as it
> can
> > > be a number, then use my simpler version.  If it can't be made into a
> > number
> > > an error is generated (as I mentioned) and the error can be trapped -
> > there
> > > is no need for prior testing.



> > > > THis is bad practive - adding a number to a string an hoping the
> variant
> > > > rules will handle it.  It would be more correct to do this:

> > > > A = CInt("0" & txtTest.Text)

> > > > And as Keld said, you may want to check for valid data first,
because
> > > > character data could be a problem.



Sun, 03 Apr 2005 21:41:15 GMT  
 
 [ 14 post ] 

 Relevant Pages 

1. converting a string to a long (string contains a Hex number)

2. Convert text and numbers to numbers

3. Converting numbers to strings to print checks????

4. Converting a string into a number.

5. Converting string to integer/number

6. Converting numbers to strings

7. Can't convert strings to positive numbers

8. Convert string in number

9. Converting a number to a character string

10. Converting string to a number (long)

11. Convert String to Number

12. type mismatch - need to convert a passed-in string to a number

 

 
Powered by phpBB® Forum Software