Except what happens if you want to test if no radio
button's .Value is True? In your scheme, you'd have to insure that at
least one radio button in the group is always selected (for example,
by setting its .Value = True, and hiding it under some other control
where the user couldn't get to it.)
Personally, I'd just loop over them, exiting my loop as soon as I
find one whose value = True
Also, I'm not sure the SELECT-CASE statement will take a Boolean
argument; I think it only accepts Integer and String type arguments
(this would work just fine in C/C++ though, as booleans are just
typedef'd integers)
Dim i As Integer
For i = 0 To ?
If radioButton(i).Value Then
Exit
End If
Next
If (i > ?) Then
// no radio button was selected.
Else
// radio button whose index is 'i' is selected
End If
On Mar 22, 2007, at 3:31 PM, Andy Dent wrote:
> I'm quoting this out of thread because it really caught my eye and I
> wanted to discuss it further and even if people disagree with the
> final conclusion, it's a neat trick and example of one of the finer
> points of RB being different from other languages.
>
> On Mar 21, 2007, at 5:02 PM, [EMAIL PROTECTED] wrote:
>
>> P.S. You could do this with a Select Case if you really want to, I
>> suppose, but it'd be an odd one:
>>
>> select case True
>> case is radiobutton(0).Value
>> ...
>> case is radiobutton(1).Value
>> ...
>> end select
>>
>> Here, you're switching based on the value of "True" by comparing
>> it to
>> several object properties. Backwards and weird, but ought to work.
>
> My immediate gut reaction was that this is code taking advantage of
> knowledge as to how the compiler works at present and should not be
> relied on to work in future.
>
> Then I thought about it a bit more.
>
> Some people swear by the C idiom of
> if (99 == myvariable) { }
>
> instead of the more readable
> if (myvariable == 99) {}
>
> to avoid the common bug:
> if (myvariable = 99) {}
> which assigns 99 to myvariable and returns 99 from the expression, so
> it has side effects and is always true.
>
> This is of course not an issue in RB because they use = for equality
> tests.
>
> So, it felt like generalisation of a common idiom and maybe makes a
> degree of sense from that viewpoint.
>
> However, I think it really should be discouraged as an idiom because
> the way it works is counter-intuitive to how it reads.
>
> In the radiobutton case it is safe.
>
> An educated programmer translates a select statement into a "match
> first true case". It's just an optimal way of writing if x then else
> if y then else if z then...
>
> However, that is when matching from variable in the select statement
> to expression in the case statement.
>
> My first reaction to 'select case True' was "that will match all the
> true cases, gee that's neat". It's not, of course, it's still just
> like a chain of if..else if...
>
> I ended up thinking;
> 1) this is still an interesting technique
> 2) you should never use it without a comment because some people will
> misinterpret it on first reading
> 3) it would really be neat to have a Select When <expr> but I can't
> think of a real-world example, just a feeling prompted by my initial
> misreading.
>
> Andy
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
