Select Case

[Guest]

Is it possible to have multiple testexpressions in a select case statement?
I want to interrogate the value of two radio buttons at once.

ex: Select Case (rdoTefraYes.Checked And rdoRetireeYes.Checked)

Case Is = True And False, Is = False And False
true and false ends up here and is ok
false and false ends up here and is ok

false and true ends up here and I expect it to show up in
the next case

Case Is = True And True, Is = False And True
true and true ends up here and is ok


This does not generate an error message, but does not seem to work either.
Three out of the four seem to work ok. Has anybody experienced this problem?
If so did you figure out a solution?

Please advise.

Thanks in advance.

Doug

 

[Niki Estner]

The expression x And y is treated equally anywhere in your code, so the code
you wrote will first calculate the logical and of "rdoTefraYes.Checked" and
"rdoRetireeYes.Checked", and then check this against "true and false" which
evaluates to "false", and against "false and false", which also evaluates to
false.
There is no direct way to acchieve what you want; You could create a
bit-mask (e.g. using a flag-enum) and select on that. If you put the
"convert-a-list-of-bools-to-a-bitmask" code into a separate function, this
could be readable code. However, IMO there's nothing wrong with a few
separate If-Then blocks if they're adequate.

Niki

PS: Using hungarian notation is discouraged, and uncommon in the .net-world.
Think about switching to the standard naming scheme.

 

[Niki Estner]

For general identifiers I agree to it hundred percent. But for UI-Controls
it is better to use hungarian notiation so that you quickly see which kind
of control that variable is.

IMO the main problems with hungarian notation are:
- everyone uses a different notation
- none of these notations is complete (i.e. there are always more types than
prefixes)
I think both of these problems are especially bad for UI controls: if you
see something like "lstXXX" you *think* this should be a listbox, while
depending on the developer it could really be a Windows-Forms-ListBox, a
Windows-Forms-ListView, some ASP.net-control, or a pointer to some IList
object. (not even speaking of custom user controls)
I definitely prefer "age20To25RadioButton" to "rdoAge20To25", because
depending on the developer and/or situation "rdo" could mean a lot of
things. (starting with "Remote Data Objects", ranging to "Responsible Dog
Ownership").
Nowadays editors are so good, we simply don't need cryptic abrevations
anymore.

(However, I do admit this is to some extent a matter of taste)

Niki

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[cody]

PS: Using hungarian notation is discouraged, and uncommon in the

IMO the main problems with hungarian notation are:
- everyone uses a different notation

First, if you start a project you have to create rules which prefix to use
for which types.
We did this in our (very large yet) project and it works very well and
everybody sticks to one convention.

- none of these notations is complete (i.e. there are always more types than
prefixes)

You do not need prefixes for *every* type. it would be very stupid to do so
(who is able to remember all of them)?
Use "lv*" for example for ListView and *all* classes derrived from it. For
everything derived from usercontrol it is a good idea to use something like
"uc*"

I think both of these problems are especially bad for UI controls: if you
see something like "lstXXX" you *think* this should be a listbox, while
depending on the developer it could really be a Windows-Forms-ListBox, a
Windows-Forms-ListView, some ASP.net-control, or a pointer to some IList
object. (not even speaking of custom user controls)

Normally ASP controls and WinForms will not appear together is an
application or even a class
and non-UI classes like IList should not use hungarian notation.

Nowadays editors are so good, we simply don't need cryptic abrevations
anymore.

If well documented and only used for WinForms classes (we count ~17 classes)
it isn't cryptic but very helpful.
For example if you want to call a method on a button and you cannot recall
its exact name,
you simply type "this.bu" and intellisense will list all buttons first and
you can now chose your button now fro the list

(However, I do admit this is to some extent a matter of taste)

Maybe.