a few beginner questions

  • Thread starter Thread starter MHoffman
  • Start date Start date
M

MHoffman

I am just learning to program, and hoping someone can help
me with the following:

for a simple calculator, a string is entered into a text
box ... how do I prevent the user from entering a text
instead of a number, or give an error message?

Also, how can I make the program verify there are two
valid entries in txtBox1 and txtBox2 to then ENABLE the
button operators (ie +, -, /, *).

Thanks for the help.
 
1)Private Sub TextBox1_KeyPress(ByVal sender As Object, _
ByVal e As System.Windows.Forms.KeyPressEventArgs) _
Handles TextBox1.KeyPress

If e.KeyChar.IsNumber(e.KeyChar) Then
e.Handled = False
Else
e.Handled = True
End If

End Sub
2)

On the TextChanged Event of one text box, call some
function....btnCalculate.Enabled = IsValid(textbox1.text) and
IsValid(textbox2.text) Where isValid is your validation routine.

On the textbox1_TextChanged add a second handles clause.... Handles
textbox1.TextChanged, Handles textBox2.TextChanged.

This will do it for you.

Cheers,

Bill
,
 
Hey, thanks for the help ... do you think you could
explain that to me though real quick? I appreciate to
know how to do it, but I want to learn to so one day I can
be richer than bill gates, (just joking, but you know that
I mean).

Also ... what about Exit Confirmation Box?

if easier, e-mail me @ (e-mail address removed)

thanks,
meredith
 
Hi

Lol. I thought it would need explaining. It's not obvious stuff. I'll
explain it all - even the stuff that you know.

1 Private Sub TextBox1_KeyPress _
2 (ByVal sender As Object, _
3 ByVal e As System.Windows.Forms.KeyPressEventArgs) _
4 Handles TextBox1.KeyPress
5 If e.KeyChar.IsNumber(e.KeyChar) Then
6 e.Handled = False
7 Else
8 e.Handled = True
9 End If
10 End Sub

1 The event handler for TextBox1's key presses.
2 sender will be TextBox1 but it is passed as an Object for simplicity
(the compiler's not ours).
3 The information about which key and other stuff is passed in a
special structure.
4 This hooks this routine to TextBox1 for KeyPress events.
5 e.KeyChar is the key that was pressed.
IsNumber tests for a digit key.
6 and 8
When a keyboard event handler returns, the caller can either say
"Oh, you've dealt with the key, I won't take it any further" or it can say
"Ah, you just looked at it but it's up to me to deal with it". In this first
case the key is effectively thrown away. In last case, the key is passed on to
the TextBox.

e.Handled tells the call;er whether the key was handled. So False means it
<wasn't> and the key should be kept and passed to the TextBox. And True means
is <was handled> and should be thrown away.

[I'd prefer it to be 'e.IgnoreKey = True'. That seems much more obvious.]

So putting it all together. If the TextBox receives a key, it will be
ignored unless it's a digit.


Part 2 coming up... :-)

Regards,
Fergus
 
Can you explain e a bit more, I am not familiar with
that ... and what does handle mean?

greatful for the explanantion though!
-----Original Message-----
Hi

Lol. I thought it would need explaining. It's not obvious stuff. I'll
explain it all - even the stuff that you know.

1 Private Sub TextBox1_KeyPress _
2 (ByVal sender As Object, _
3 ByVal e As
Click to expand...
System.Windows.Forms.KeyPressEventArgs) _
4 Handles TextBox1.KeyPress
5 If e.KeyChar.IsNumber(e.KeyChar) Then
6 e.Handled = False
7 Else
8 e.Handled = True
9 End If
10 End Sub

1 The event handler for TextBox1's key presses.
2 sender will be TextBox1 but it is passed as an Object for simplicity
(the compiler's not ours).
3 The information about which key and other stuff is passed in a
special structure.
4 This hooks this routine to TextBox1 for KeyPress events.
5 e.KeyChar is the key that was pressed.
IsNumber tests for a digit key.
6 and 8
When a keyboard event handler returns, the caller can either say
"Oh, you've dealt with the key, I won't take it any further" or it can say
"Ah, you just looked at it but it's up to me to deal with it". In this first
case the key is effectively thrown away. In last case, the key is passed on to
the TextBox.

e.Handled tells the call;er whether the key was handled. So False means it
<wasn't> and the key should be kept and passed to the TextBox. And True means
is <was handled> and should be thrown away.

[I'd prefer it to be 'e.IgnoreKey = True'. That seems much more obvious.]

So putting it all together. If the TextBox receives a key, it will be
ignored unless it's a digit.


Part 2 coming up... :-)

Regards,
Fergus


.
Click to expand...
 
Hi Herfried,

Better:

'Ignore the Key if it is not a digit.
e.Handled = Not Char.IsNumber(e.KeyChar)

<My> SCNR! :-))

Regards,
Fergus
 
Guys, you are confusing me here, which way should I use?
the shorter or the if then?

thanks,
feeble minded beginner programmer
meredith
 
Hi again M,

Lol. No problem. :-)

Let's have another look at it :

1 Private Sub TextBox1_KeyPress _
2 (ByVal sender As Object, _
3 ByVal e As System.Windows.Forms.KeyPressEventArgs) _
4 Handles TextBox1.KeyPress
5 If e.KeyChar.IsNumber(e.KeyChar) Then
6 e.Handled = False
7 Else
8 e.Handled = True
9 End If
10 End Sub

When an event, like receiving a key press or a mouse action, occurs to a
Control, in this case a TextBox, a message is sent to the Control to inform it
about what's happened. All events that happen to Controls are handled by
built-in code but there is also the option for the <user> of the Control to
take some additional action. In your case it's discarding non-digit
keystrokes. Finally, the Control may trigger an event <itself> specifically
for the user. Dealing with events, ie. handling them, is optional.

You can hook into an event by installing what's called an Event Handler.
This is a routine which takes a particular form as shown by lines 1 to 4. The
'Handles' keyword tells the compiler that this Sub will handle events 'raised'
by the following Control and for the given event. In this case it's TextBox1
and the KeyPress event.

Note that this is a list and you can have more Controls, eg:
1 Private Sub AllMyTextBoxes_KeyPress _
2 (ByVal sender As Object, _
3 ByVal e As System.Windows.Forms.KeyPressEventArgs) _
4 Handles TextBox1.KeyPress, TextBox2.KeyPress, _
5 txtAddressA.KeyPress, txtAddressB.KeyPress, etc

The name used in line 1 is completely arbitrary but the convention is to
have the Control name, an underscore and then the event name.

The arguments to an event handler are predefined.

'sender' is the Control to which the event happened and is an Object. This
is so that the same mechanism can be applied to any Object that can raise an
Event. I don't like the name myself. I never think in terms of a Control or
Object 'sending' an event. That, to me, is practically meaningless. I would
prefer VB to insert 'TheTextBox' or some name tailored to the Control or
Object. Ah, well.

'e' is another stupid name. It's a shorthand for EventArgs but it's
brevity goes against one of the key style principles of .NET, namely, long
names for better understanding*. e is always an object containing information
about the Event. In the case of a KeyPress, it will be KeyChar - the key that
was pressed and Handled, a variable, the setting of which, allows you to
discard the keystroke. (Empty and GetType() are the other two, which I will
ignore). [* However, saying that, I like g for Graphics! :-)]

Hooking into an Event.

This is done for you when you double-click a Form or Control, although it
only works for the default event. VB will write the outline of the required
Sub. You can get the other events for a Control by going into the top-left box
above the code for the form (I don't know what the box is called but it
usually shows the Form name) and selecting (Base Class Events). This will
put - in the <top-right> box - the events that your control can handle. Click
on the one you want and <that> event's Sub will be writen for you. Finally, if
you know what you are doing, you can simply type it in.

[If you ever get into C#, hooking into events take a bit more effort and
thereby teaches you the mechanism a bit better. You'll learn the same when you
get into Delegates in VB. Later, dude, much later :-)]

Ok, that's Events 101. Keep asking. We'll get you there! :-)

Regards,
Fergus
 
Hi Herfried,

What's the objection - using comments or the comment I used?

;-)

Regards,
Fergus

ps. I know it's the latter but what don't you like about my comment? And what
would your preferred comment be?
 
Hi Meredith, Herfried,

Nice to know your name, Meredith :-)

Sorry if that was confusing. Shorter is better when you are comfortable
with it. Comments should be used when there is any doubt or when the code does
something techie which doesn't explain what it's doing in conceptual terms.

Handled = False is techie for 'keep the key'
Handled = False is techie for 'throw the key away'.

e.Handled = Not Char.IsNumber(e.KeyChar) is techie for "keep the key only
if it is a digit".

I disaprove of such code when it obscures the meaning. To understand it
you have to do some mental hoop-la before you know which way it jumps. - Ok,
I've got a key and it <is> a number, so <Not that> means it's False, so
Handled = False, now that means I <haven't> dealt with the key so that I <do>
want to keep it. Okay. Glad <that's> clear. Now if it <isn't> a number key
then......

At least with a comment you can know what the code is doing, even if
checking it <still> requires the mental walk-through.

As experienced programmers, Herfried and myself can cope with compacted
statements. I usually write my code on the assumption that a (near) beginner
is going to take it over from me eventually. As that beginner programmer,
Meredith, you should write code that clear to <you>. Learning is your priority
at this stage.

Regards,
Fergus

ps. "feeble minded beginner programmer" is not 'allowed' when you're talking
to me, lol. You should be proud of having entered the arena, not apologetic.
Better to be assertive with a smile, eg "beginner programmer - gimme a break
;-)".
Besides 'feeble minded' and 'programmer' is a contradiction in terms. :-)
 
Hi Herfried, Meredith,

Better versus shorter:

If shorter means more efficient and efficency is <utmost> then shorter.

If shorter means you can see more on the page and you're me, then shorter.
Probably.

If shorter means cryptic - and clarity and understanding are important
(>95% of the time?) then longer.

If shorter means cryptic then comment and explain. (Which makes it longer
anyway!)

IMHO, lol.

Regards,
Fergus
 
Hi Herfried, Meredith,

Better versus shorter:

When shorter means not cryptic (skip this Meredith: by instance regex) than
shorter is in my opinion always better.

It is more readable, easier to keep up, better to trace, what not and seldom
it means more CPU power.
With some exceptions by instance graphical and sound questions, that are
very processor bound.

:-)
Cor
 
Hello,

Fergus Cooney said:
What's the objection - using comments or the comment I used? [...]
ps. I know it's the latter but what don't you like about my
comment? And what would your preferred comment be?
Click to expand...

IMO comments of this type are pretty useless:

\\\

' Increment i by 1.
i = i + 1
///

It's more important to describe _why_ we do that.
 
Back
Top