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 ?

[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....
"Homer J Simpson" <no****@nowhere .com> wrote in message
news:vwntf.2559 6$OU5.24963@clg rps13...

"Scott M." <s-***@nospam.nosp am> wrote in message
news:uz******** *****@TK2MSFTNG P12.phx.gbl...

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).

You'll never get it.

[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.
"Rob" <rw*****@comcas t.net> wrote in message
news:Ss******** *************** *******@comcast .com...

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....
"Homer J Simpson" <no****@nowhere .com> wrote in message
news:vwntf.2559 6$OU5.24963@clg rps13...

"Scott M." <s-***@nospam.nosp am> wrote in message
news:uz******** *****@TK2MSFTNG P12.phx.gbl...

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).

You'll never get it.

[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]

"Scott M." <s-***@nospam.nosp am> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..

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?

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
(TechTrainSolut ions.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(Tex tbox1.Text, Double) + CType(Textbox2. Text,
Double), String)
"Scott M." <s-***@nospam.nosp am> wrote in message
news:eT******** ******@TK2MSFTN GP09.phx.gbl...

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