Subtraction from a Textbox

NickJ

Member
Joined
Apr 29, 2005
Messages
21
Programming Experience
Beginner
Hi
Could anyone please help with this .....

Im try to subtract the value of textbox1 from label1.

Then I need to divide label1 by textbox2

Would be easier if i made Label1 into a textbox?




Thanks people

Nick
 
Like I said, trying to convert an empty string to a number will throw an exception. This is almost certainly what is happening in your case. You need to validate the string to make sure it represents a valid number. You might look into the Double.TryParse method. I would recommend making the changes to use NumericUpDowns, though. In my opinion, they should always be used where they can and only resort to a TextBox if there is some specific reason to. There are valid reasons to use TextBoxes for numerical input, but this usually relates to variable numbers of decimal places. If you're using Integers then the NumericUpDown is usually better. Let's say you are switching from TextBox1 to NumericUpDown1. You can simply do a Find and Replace to switch "TextBox1.Text" to "NumericUpDown1.Value".
 
Use CInt

You should keep CInt. The others were mistaken in saying otherwise. :)

To quote Microsoft's MSDN online help for VB 2005,
"As a rule, you should use the Visual Basic type conversion functions in preference to the .NET Framework methods such as ToString(), either on the Convert class or on an individual type structure or class. The Visual Basic functions are designed for optimal interaction with Visual Basic code, and they also make your source code shorter and easier to read."
( http://msdn2.microsoft.com/en-us/library/s2dy91zy(d=ide).aspx )

As the page makes clear, "Visual Basic type conversion functions" means CInt, CDec, etc, and also CType, DirectCast, TryCast where these are applicable.
 
What is it with Microsoft and trying to confuse people.

We move from VB6 rubbish to a proper class framework and they keep old functions that dont seem to even be a part of the object heirarchy. And they recommend you use them over the new Convert class! Is it me, or does this just seem really stupid??

It the good old M$ way of training people to do things in such a way that it makes it hard to learn competing language/program/method - the new stuff doesnt make sense because youve learnt things backwards.

They copied all the good stuff from Java, and then threw in a load of crap.

eg,
Dim a(0) As String
Console.Writeline(a.Length)


Result? 1.
Hmmm

And before anyone says it - I know, I should be coding C#.. ;)

</rant>
 
Ok i've has look into this and in my opinion CInt Or Convert.ToInt32 - Who Cares, to say that CInt is the old VB way of doing things is incorrect because you dont have to add a reference to the visualbasic.compatibility namespace to use it. It is therefore part of the object hierachy and a viable entity in vb.net. However they do differ in the way they calculate, for example...

CInt(0.5) will return 0 which should be impossible because 0.5 is not an integer

convert.toint32(0.5) will throw an exception because it correctly determines that 0.5 is not an integer

As for which one to use, i would personnally use CInt because it's faster to type and it highlights in blue so it makes for easier code readability. If that sounds lazy, well then call me lazy but with the amount of typing that all programmers do it is always better to write less code in that regard.
 
Visual Basic .NET/2005 has many ways to convert values. Some of them are updated versions of VB6 techniques while some was added in the new version(s).
However, many programmer are using these short conversion method which most VB6 programmers are familiar with. These methods for conversion of primitive datatypes are boxing the value type which has performance implication.
For example, CStr class will convert primitive type to a String but it has an advantage. It is that CStr is designed to support any object which means that if primitive type is used the method CStr automatically boxes the parameter prior to getting the new value.
This result in a loss of performance.
The conversions run faster when the members of the Convert class are called explicitly (Convert.ToInt32(value)).
Finally, althrough Cint(0,5) will compile it will not always execute correctly just like in you case. Means it is not about what you like but rather what is best for your application.
Regards ;)
 
Back
Top