Need help with a little VB

[jneul]

Thanks for pointing the out another great way to solve his problem, but the whole point of us doing that is so he still had to do some work, now you've handed the solution to him, how on earth is he going to learn??

 

[Jason]

Thanks for the help people, especially Alexander for making it really simple, haha.

Alexander, I've just got a few of questions;

Would you be able to explain, well, this;

 

Private Sub CalculateField_TextChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles txtTerm.TextChanged, txtPrincipal.TextChanged, txtInterestRate.TextChanged

 

Also, what is Me. needed for before the button and text syntax

And last question, would AndAlso work in the same way as something like;

= (A > 0 And B > 0 And C > 0)

Does it give the same effects, or is it completely different to what I'm thinking ?

-----------------

Also, just thought I'd show you what I've got of it at the moment (It's pretty much finished now) so you know what you've been helping me with;

 

[Jason]

Also, jneul

If someone DOES do it for me, then I ask questions as to HOW they did it, so I can replicate it myself lol... first I just need to understand some bits and bobs.

 

[jneul]

Thanks for the help people, especially Alexander for making it really simple, haha.

Alexander, I've just got a few of questions;

Would you be able to explain, well, this;

 

Private Sub CalculateField_TextChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles txtTerm.TextChanged, txtPrincipal.TextChanged, txtInterestRate.TextChanged

 

Also, what is Me. needed for before the button and text syntax

And last question, would AndAlso work in the same way as something like;

= (A > 0 And B > 0 And C > 0)

Does it give the same effects, or is it completely different to what I'm thinking ?

Ok here goes --
right every time you change the contents of any of the named text boxes (txtTerm, txtPrincipal and txtInterestRate) they will trigger their TextChanged event, and then it will also execute anything held in that above function, that is why it is so important that all your checks go in that function, because you need to check every time one of theose text boxes change ok.

AndAlso does not work exactly the same way as And

here is an example

If A > 0 AndAlso B>0 AndAlso C>0

Lets say a is more than 0 but B is 0, the program will stop any futher checks at that point because it will know that the result is false, however if you use And it will check all of them and then return the value of false afterward, thats why Alexander said it was better and he is right.

Edit: of course thats fine if you ask questions, it will help you out i hope.
I hope my explanation of things is not too much lol, i have tried to make it simple as possible.

 

[Jason]

Ah yeah, that's pretty simple to understand, am I right in saying that And would just check A, B and C separately, while AndAlso would check all three together ?

 

[jneul]

no the other way around, using And in that case means the program will check all three, using AndAlso in that case will only check just two and then return the result.
oh btw Me was the name we gave to our form containing our controls, you dont have to access members that way sorry, how lazy of me lol

 

[Alexander Morou]

Me is primarily used to clarify the identity of the term used. Let's say you're in a method that used a value named 'bob' and your class had a value named 'bob', to differentiate between the two, you'd use 'Me.bob'. An example is if you set the class' bob to the local bob:

Me.bob = bob

jneul, the only reason for 'handing it to him' was to clarify the points where it changed. Your example showed TextBoxN, where 'N' was the ordinal of the given textbox, mine used names relative to his specific problem. The thing you forgot to point out in your example is to replace the names of the ordinally named boxes with names pertinent to his specific issue.

Essentially 'Handles' creates a link between the Sub procedure and the event(s) mentioned, so long as the signature of the Sub procedure matches the signature of the event.

So if you had a sub named 'bob_died' that handled bob's 'Death' event, you'd write it like so:
Sub bob_died(ByVal sender As Object, ByVal e As EventArgs) Handles bob.Death
MessageBox.Show("Bob Died! :O")
End Sub

Naturally this assumes that 'bob' is a local (aka. variable) defined in the active scope, and it is of a type which contains an event named 'Death'.

The name of the actual sub procedure is irrelevant in most cases (except in cases where you're trying to be clear about the intent of the procedure, and what it does). So you could handle event 'A43333' in sub 'X05', as long as you specify the 'Handles' portion properly, it will handle it properly.

If I'm unclear here, I apologize, I'm tired; I work nights.

 

[Jason]

Lol nope, you were very clear, and I don't know why, but I kinda laughed at the idea of some guy called Bob dying, and how I could add it into my Interest Calculator...

If you input the Term (Year) over 80, it'll say "Bob died while waiting for his interest" o.O

Yeah, weird eh...

But thanks for explaining it anyways :thumb:

 

[jneul]

its ok don't worry, but like you said naming of procedures can be important though it helps to maintain tidy code, and also if you give it an name representing what it does, then it helps you remember what you made the function for.
we was always encouraged to give our sub procedures and variables meaningful names, also we had to give our variables certain prefixes to help identify their types as well so say if i had a boolean variable in a class we had to start it with a prefix of m_b just to identify it was a boolean to other programmers looking and handling our code.