a few beginner questions

  • Thread starter Thread starter MHoffman
  • Start date Start date
Hi Herfried,

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

I totally agree that the above has nothing to offer as a comment (although
there are beginners who start out with this level of commenting).

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

conveys much more information. My post two steps above explains why I
believe so.

Regards,
Fergus
 
Hello,

Fergus Cooney said:
|| ' Increment i by 1.
|| i = i + 1

I totally agree that the above has nothing to offer as
a comment (although there are beginners who start out
with this level of commenting).

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

conveys much more information. My post two steps
above explains why I believe so.
Click to expand...

I don't agree. I place comments only to describe something that cannot be
seen when having a quick look at the source code. I do not include things
in my comments that help beginners to understand the code (syntax of the
programming language or the API). I assume the reader of the code to be
familiar with both. 'e.Handled = Not Char.IsNumber(e.KeyChar)' is IMO
really self-descriptive: "The character is handled if it is not a number".
 
Hello,

Fergus Cooney said:
Better versus shorter:

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

In our case efficiency is not that important.
If shorter means you can see more on the page and you're
me, then shorter. Probably.
ACK.

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

I think the line 'e.Handled = Not Char.IsNumber(e.KeyChar)' describes
exactly what and how I think. It doesn't reduce clarity and understanding
(IMO).
If shorter means cryptic then comment and explain.
(Which makes it longer anyway!)
Click to expand...

Yep.
 
Hello,

Cor said:
Better versus shorter:

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

'Regex' _can_ be shorter and less cryptic. This depends on the case. Why
not use advanced techniques only because beginners don't understand them?
 
Hi Herfried,
That has nothing to do with beginners, the point for me in VB is, that it is
quiet easy to read as a natural document.

For me the first rule in architecture, documentation and programming is to
keep it simple

Someone else has to be able to read it in a quick look.

Therefore I try to avoid sophisticated commands that are not direct
meaningful or commands that needs comments

(Not ban them, if a process is in an often used loop, I try every command to
shorten that, I never did it but after that nice example from Fergus maybe
even the Regex)

On the other hand, I use always very complex program control structures.

By instance do I find functions like Mid, and Len more meaningful than
substring and length,

Of course you disagree that with me.

You are right because of the zero indexes and the generality I choose for
the String members.

:-)
Cor
 
Hello,

Cor said:
That has nothing to do with beginners, the point for me in VB is,
that it is quiet easy to read as a natural document.
Click to expand...

;-)

I think you really understood the meaning of "BASIC".
For me the first rule in architecture, documentation and
programming is to keep it simple

Someone else has to be able to read it in a quick look.

Therefore I try to avoid sophisticated commands that are
not direct meaningful or commands that needs comments
ACK.

shorten that, I never did it but after that nice example from
Fergus maybe even the Regex)
Click to expand...

This depends on the case. For really complex string matching, extraction
and replacement routines it's sometimes "impossible" to write a solution
without using Regex because it would become much more complex and hard to
change and understand than the Regex solution.
By instance do I find functions like Mid, and Len more
meaningful than substring and length,
ACK.

Of course you disagree that with me.
Click to expand...

I don't disagree.
 
Hi,I know you don't disagree that, but I use the String members, that is
inconsequent with my text, so I had to tell why.
:-))
Cor
 
Hello,

Fergus Cooney said:
Handled = False is techie for 'keep the key'
Handled = False is techie for 'throw the key away'.
Click to expand...

Typo:

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

That's why I prefer the short version.

;-)
 
The code worked in one way, and not another :(

Now I cannot type a "." for decimals! Its great to know
how to enter a number only, how do I tell the program to
only allow digits and a few other keys, like the period,
the regular enter, backspace ... etc.

Also, I tried to add the code to have the calculator
validate that an entry was in txtBox 1 and 2 before
Enabling the Operation buttons, but I couldn't figure it
out. SHould I already know how to Validate, because I
don't :).

Thanks for all the info!

-----Original Message-----
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
Click to expand...
 
Hello,

meredith said:
Now I cannot type a "." for decimals! Its great to know
how to enter a number only, how do I tell the program to
only allow digits and a few other keys, like the period,
the regular enter, backspace ... etc.

Also, I tried to add the code to have the calculator
validate that an entry was in txtBox 1 and 2 before
Enabling the Operation buttons, but I couldn't figure it
out. SHould I already know how to Validate, because I
don't :).
Click to expand...

Why not use a NumericUpDown control or validate the textbox's contents in
its 'Validating' event? Restricting the user to some keys is always a bad
idea. When uding 'KeyDown' to suppress some keys, the user will still be
able to paste text into the texbox.
 
Hi Herfried, Meredith,

|| Why not use a NumericUpDown control.

Lol, It won't take long to get to 3675 and not much longer to reach
438173. :-)

|| or validate the textbox's contents in its 'Validating' event?

Because Meredith wants dynamic reaction. The [+], [-], [*], [/] buttons
enabled as and when and only when the inputs are valid, ie per character.

|| Restricting the user to some keys is always a bad idea.

Is it? Always? Lol.

I think you should prevent the user doing what they shouldn't then you
don't have to tell them off when they get it wrong. ["No, you can't type a
letter into the calculation", or even better "Data Error", or better still
"Error 54"]

|| When using 'KeyDown' to suppress some keys, the user will
|| still be able to paste text into the texbox.

Now you're making sense. I faced exactly the same problem when I did this
exercise.

=================================
Meredith,

One option on validation is that you let the user do what they want but if
a box has a bad value, set its background to some suitable colour, eg light
red. and put the nature of the error in the status bar. This informs the user
of the error without interrupting them with dialogue boxes. It also allows
them to intentionally use cut-and-paste to bring in mixed data, eg "23 Files",
and edit out the rubbish - again without pesky interruptions from a dialogue
box.

In this case you would act upon the TextBox_Change events. If the text is
not empty and contains only digits then set it's background to the 'good'
colour and clear the status panel for that box. Otherwise set it to the 'bad'
colour and put a message in the status bar panel for that box. Then do the
same for the other text. Then, if both are ok, enable the calculation buttons.
Otherwise disable them.

By the way, allow leading and trailing spaces in the input. It's annoying
to a user to have to delete spaces which <they> know don't matter. Especially
if the font makes them narrow and they haven't wiped their glasses. But, of
course, take them off before using the number.

This makes for a very unintrusive UI - informative, obvious and with no
interruptions to the user's work flow. There's no harm in keeping the
disablement of alpha/punctuation keys.

Hope this gives you some ideas. :-)

Regards,
Fergus
 
Hi Meredith,

See my response to Herfried for some ideas. I'll assume that you've read
that one first.

Whatever you did to allow the digit keys to go through, you have to do the
same for the special keys that you are interested in. Use the Keys
enumeraction to get the key values for the full stop (Keys.Decimal?), etc.

Write a function that takes a string and returns true if it's valid and
creates a meaningful error message if it's not.

Validition:
On copy of the string (ie ByVal parameter)
Strip the leading and traiing spaces
Allow a single "-" at the front. Remove it. Strip leading spaces.
Check for any more "-"s. Error - "Only one minus is allowed and it
must be at the front."
Check for "." and, if found, remove it.
Check for ".", and if found. Error - "There may only be a single
decimal point"
Check for non digits. Error - "Numbers may only contain a minus,
digits and a decimal point"

Like I say in the other post. Validate both texts separately and put their
error messages in their respective status bar panels. Use the combination of
both validities for button enabling.

That should keep you busy for a while. :-)

Let us know how you are getting on. You may want to post your code.

See you later,
Fergus
 
Back
Top