 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / VB.NET / December 2005Bound text box
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 ? 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 > Assume 3 controls on a form.... > [quoted text clipped - 3 lines] > > How do you hardcode this to Textbox3 ? 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") > Assuming you have already validated that the first 2 textboxes do, in fact > contain numeric data: [quoted text clipped - 20 lines] >> >> How do you hardcode this to Textbox3 ? A simple way to do it is in the textchanged event of textbox1 and textbox2 > Thanks Scott, > [quoted text clipped - 27 lines] > >> > >> How do you hardcode this to Textbox3 ? 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. > Thanks Scott, > [quoted text clipped - 27 lines] >>> >>> How do you hardcode this to Textbox3 ? > 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 > 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 [quoted text clipped - 8 lines] > > 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. >> In VB6 you'd use the Textbox1_Change and Textbox2_Change events. >> [quoted text clipped - 22 lines] > 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. > 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). >> 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. [quoted text clipped - 9 lines] > Both scenarios are simplistic, it's a usability issue (and with my > solution, there is less code to add). You'll never get it. 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.... >>> 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. [quoted text clipped - 11 lines] > > You'll never get it. 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. > Thank you both for responding... > [quoted text clipped - 30 lines] >> >> You'll never get it. > 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'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 [quoted text clipped - 6 lines] > 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. > 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! 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 Correction: Textbox3.Text = CType(CType(Textbox1.Text, Double) + CType(Textbox2.Text, Double), String) > By the way, your line of code: > [quoted text clipped - 14 lines] > > -Scott Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.