Bound text box

[Rob]

Assume 3 controls on a form....

Textbox1, Textbox2, and Textbox3

If you want Textbox3 to equal Val(Textbox1) + Val(Textbox2)..

How do you hardcode this to Textbox3 ?

 

[Scott M.]

Assuming you have already validated that the first 2 textboxes do, in fact
contain numeric data:

Textbox3.Text = CType(Textbox1.Text, Double) + CType(Textbox2.Text, Double)

Or, for better exception management:

Dim x, y, z As Double
Try
x = CType(Textbox1.Text, Double)
y = CType(Textbox2.Text, Double)
z= x + y
Catch e As Exception
Textbox3.Text = "You must enter only numeric data!"
End Try

 

[Rob]

Thanks Scott,

My "real" question is.... where do you put the code ? Let's say you are
using the designer... May I put "= CType(Textbox1.Text, Double) +
CType(Textbox2.Text, Double)" into a property of TextBox3... or must it be
Event driven (i.e., "On Click")

 

[toufik]

A simple way to do it is in the textchanged event of textbox1 and textbox2

 

[Scott M.]

You generally put your code into event handlers or methods that are then
called by other code.

There are many events you can choose from, but the first thing you want to
do is identify "when" do you want your code to execute. You wouldn't put
any of this code into anything that has to do with Textbox3 because you want
to see the answer when someone clicks a button (most likely), so the code
goes into the click event of the button you add to the form.

 

[Homer J Simpson]

Thanks Scott,

My "real" question is.... where do you put the code ? Let's say you are
using the designer... May I put "= CType(Textbox1.Text, Double) +
CType(Textbox2.Text, Double)" into a property of TextBox3... or must it be
Event driven (i.e., "On Click")

In VB6 you'd use the Textbox1_Change and Textbox2_Change events.

Why not TextBox?_TextChanged ?

Private Sub TextBox1_TextChanged(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles TextBox1.TextChanged
TextBox3.Text = TextBox1.Text & TextBox2.Text

End Sub

Private Sub TextBox2_TextChanged(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles TextBox2.TextChanged

TextBox3.Text = TextBox1.Text & TextBox2.Text

End Sub

 

[Scott M.]

In VB6 you'd use the Textbox1_Change and Textbox2_Change events.

Why not TextBox?_TextChanged ?

You could put this code into a TextChanged event, but it is not the most
common approach (and wasn't in VB 6.0 either). Generally, a button is
created explicitly for users to click to cause some calculation.

Private Sub TextBox1_TextChanged(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles TextBox1.TextChanged
TextBox3.Text = TextBox1.Text & TextBox2.Text

End Sub

Private Sub TextBox2_TextChanged(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles TextBox2.TextChanged

TextBox3.Text = TextBox1.Text & TextBox2.Text

End Sub

Your code above isn't really the best approach because you have written the
same thing in 2 places. Now, sure you could create a third procedure that
the first two call so that the code isn't duplicated, but this is besides
the point. The point is to determine which *event* you want to trigger the
code.

 

[Homer J Simpson]

You could put this code into a TextChanged event, but it is not the most
common approach (and wasn't in VB 6.0 either). Generally, a button is
created explicitly for users to click to cause some calculation.


Your code above isn't really the best approach because you have written
the same thing in 2 places. Now, sure you could create a third procedure
that the first two call so that the code isn't duplicated, but this is
besides the point. The point is to determine which *event* you want to
trigger the code.

The code I gave him was the simplest possible solution and it worked. From
that he can add as much complication as he desires. KISS.

 

[Scott M.]

The code I gave him was the simplest possible solution and it worked. From

that he can add as much complication as he desires. KISS.

You think writing the same code in 2 different places is the simpleset
solution? Uh, well ok.

As I said earlier, it's really a matter of choosing between TextChanged and
a button's Click event handler (as you say, they both work) but there are
those who believe (me among them) that you should give the user a control to
interact with in order for an operation to be triggerd.

Both scenarios are simplistic, it's a usability issue (and with my solution,
there is less code to add).

 

[Homer J Simpson]

You think writing the same code in 2 different places is the simpleset
solution? Uh, well ok.

As I said earlier, it's really a matter of choosing between TextChanged
and a button's Click event handler (as you say, they both work) but there
are those who believe (me among them) that you should give the user a
control to interact with in order for an operation to be triggerd.

Both scenarios are simplistic, it's a usability issue (and with my
solution, there is less code to add).

You'll never get it.

 

[Rob]

Thank you both for responding...

Here is the situation....

I am coming from MS-Access where you may bind a formula directly to a text
box...

What the user's like about this approach (in a Quote providing application)
is that they do not have to do anything to see a "Total" on the form... the
Total gets created as the user add components....

So in Access, you can code such that if the texbox is null, don't show a
total, otherwise, let them see the $ amount... without having to click a
button.

As far as programming goes... I would like to have an "Update Total" button,
but do not know how user's will like that....

 

[Scott M.]

I hear what you are saying, but although you may find the automatic
calculation connected directly to the textbox a nice feature, general
usability standards would say you should have a button to perform the
operation (or at least a button in addition to the automatic calculation).

It is certainly possible (as I've said) to attach your code to the
TextChanged event of the textboxes and then have each event handler call a
dedicated routine to do the operation. That's not *wrong*. I'm merely
saying that there are certain aspects of a well-created UI that should be
given consideration and having a button to click is one of them.

 

[Scott M.]

You'll never get it.

Not if you don't explain what it is you are trying to say, I won't. You
stated that your solution was the simplest possible one, and then touted the
KISS principal as if what I showed was somehow rocket science. You and I
showed the same thing. The only difference is that you put your code in 2
places and have it being invoked from the TextChanged event and I put it in
one place and have it being invoked from a button's Click event.

Now, tell me again how your solution is the simplest and what it is that I
don't get?

 

[Homer J Simpson]

Not if you don't explain what it is you are trying to say, I won't. You
stated that your solution was the simplest possible one, and then touted
the KISS principal as if what I showed was somehow rocket science. You
and I showed the same thing. The only difference is that you put your
code in 2 places and have it being invoked from the TextChanged event and
I put it in one place and have it being invoked from a button's Click
event.

Now, tell me again how your solution is the simplest and what it is that I
don't get?

You are in an education mode. This user requires the simplest possible
solution. Once he sees it working he can add whatever complication or
enhancements he desires. This is how to teach:-

First, show him a bubble sort. Demonstrate that it works.
Second, show him how slowly it works.
Third, show him a Shell sort. Now he understands.

BTW, a one line routine is not optimized for speed or size by calling it as
a subroutine instead of running inline.

 

[Scott M.]

You are in an education mode. This user requires the simplest possible

solution. Once he sees it working he can add whatever complication or
enhancements he desires.

I'll ask you again (third time) how puting the code in two different places,
rather than just one is the simplest possible solution? Since your code and
mine are the same, the only difference becomes where it is put and how much
coding is involved. Your code works perfectly fine, but requires more code
to make it work (and more maintenance if the calculation were to change), so
what is it that you believe is simpler than one line of code:

TextBox3.Text = TextBox1.Text & TextBox2.Text

Really, step off your high horse for a second and think about this. This is
ONE line of code put in ONE place - - seems pretty darn simple to me.

This is how to teach:-

First, show him a bubble sort. Demonstrate that it works.
Second, show him how slowly it works.
Third, show him a Shell sort. Now he understands.

Thanks for the tip. Since I own and operate a technology training company
(TechTrainSolutions.com) and have been doing IT education for 15 years and
assorted industry training for 10 years before that, I'll stick to my
methodology, which works exceptionally well thanks. It's based on
well-known education principals for teaching adults (which is different than
how you teach children).

BTW, a one line routine is not optimized for speed or size by calling it
as a subroutine instead of running inline.

That's not necessarially true. There are several reasons why repeating the
same calculation in more than one place is a bad idea, poor technique and
why just about every professional developer will tell you so:

1. It's not good because if the calculation/algorythm needs to change, you
have to change it in more than one place.
2. It's not good because you may miss one of the places it needs to be
updated.
3. It also opens the door to the possibility that the two (or more) lines
will inadvertently become different from each other, causing unexpected
results.

As for optimization, calling a method rather than doing the operation from
one within one method will have virtually no impact on performance. In
other words, contrary to your statement, a one line routine's performance is
not impacted by the fact that it needs to be called from another method.

It seems to me that you just want to argue no matter what is said. If you
believe your technique is better, great - use it. But, please don't make
claims that are incorrect and have no basis in fact.

Happy New Year!

 

[Scott M.]

By the way, your line of code:

TextBox3.Text = TextBox1.Text & TextBox2.Text

wouldn't produce the mathematical addition of the two values in either VB
6.0 or VB.NET, it would produce the concatenation of the two values.

The correct VB.NET statement is:

Textbox3.Text = CType(Textbox1.Text, Double) + CType(Textbox2.Text, Double)

The CType function calls are required because Option Strict should be turned
on at all times (you knew that, right?) and with Option Strict turned on,
you can't attempt to add Textbox values (or do any math at all) without
casting the value first.

-Scott

 

[Scott M.]

Correction:

Textbox3.Text = CType(CType(Textbox1.Text, Double) + CType(Textbox2.Text,
Double), String)