Are option groups really, really dumb in VBA?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am getting "Run-time error '2427': You entered an expression that has no
value" when I refer to an option button's value:

If Me.optFindAll.Value = vbTrue Then ...

However, I had set this option button as the default when I created the
option group. Do I still have to explicitely assign a default value to it in
code, before I can use it?

Also, what is there to gain by assigning unique OptionValue values to each
option button in a group if they have to be referred to individually, anyway?
(That is, if I have to test each option button to see if its value is true,
then what is the point of giving them OptionValues like 1 or 2 ?)

-- Confused
 
If you have an option group with multiple options, you just need to check
and/or set the value of the option group not the value of the individual
options, like:

If me.NameOfYourOptionGroup = 1 then
do something
end if
 
no, they're not - but sometimes people don't understand how to write code to
use them. the value of an option group control is equal to the OptionValue
property of the selected option button. for instance, say you have an option
group control named grpChoice, with three option buttons that have a
OptionValue of 1, 2, and 3, respectively. if you want particular code to run
depending on which option button is selected, the usually the easiest way is
to use a Select Case statement, as

Select Case Me!grpChoice
Case 1
<put your code here>
Case 2
<put your code here>
Case 3
<put your code here>
End Select

of course, you can use an If statement if you prefer, as

If Me!grpChoice = 1 Then
<put your code here>
ElseIf Me!grpChoice = 2 Then
<put your code here>
ElseIf Me!grpChoice = 3 Then
<put your code here>
End If

note that regardless of whether you use a Select Case statement or an If
statement, you're checking the value of the *option group control*, NOT the
OptionValue property of an individual option button within that control.

hth
 
As tina explained, you need to examine the value of the group.
The option group has a value.
The individual option buttons in the group do not.

You can compare the value of the group to the OptionValue of each button if
you like. That way the code doesn't have to be re-written if you swap the
buttons around. This kind of thing:
Select Case Me.!grpChoice
Case Me.opt1
<put your code here>
Case Me.opt2
<put your code here>
Case Else
MsgBox "Oops: you forgot to code for option " & Me!grpChoice
End Select
 
Darn, got distracted. Should have been:

Select Case Me.!grpChoice
Case Me.opt1.OptionValue
<put your code here>
Case Me.opt2.OptionValue
<put your code here>
Case Else
MsgBox "Oops: you forgot to code for option " & Me!grpChoice
End Select
 
Thanks, everybody.

Okay, I see that they aren't "really, really dumb", but compared to VB, they
are a little dumb in that you can't refer to a member of the option group via
an index, as in
optStuff(0), optStuff(1), ...

but, rather, you have to keep track of the individual names for each member
and use different event routines (if required) for each.
 
Allen_N said:
Thanks, everybody.

Okay, I see that they aren't "really, really dumb", but compared to
VB, they are a little dumb in that you can't refer to a member of the
option group via an index, as in
optStuff(0), optStuff(1), ...

but, rather, you have to keep track of the individual names for each
member and use different event routines (if required) for each.
Click to expand...

But ... when do you ever have to refer to the individual option control?
All the action takes place for the option group frame.
 
but, rather, you have to keep track of the individual names for each
member
and use different event routines (if required) for each.
Click to expand...

well, no, you don't have to do any of that - just use the option group the
way it was designed to be used. perhaps it would help you if you re-read my
first post to this thread, and re-read Allen Browne's first and second
posts, as well.

hth
 
Allen, it might help to understand that the differences between pure VB
forms/code and Access forms/code is that Access is data-centric.

So, if a VB form has a text box, and its default property is Text (whatever
is in the text box at present.) But if an Access form has a text box, its
default property is Value. The Text property applies only while the control
has focus. Before focus leaves the text box, Access attempts to convert the
Text into the Value. That could fail. For example if you typed "hello" into
a text box bound to a Number field, the Access data engine rejects the
value, and you are now stuck in the box until you enter a valid number (so
the Text can be converted to the Value), or undo it (so there is no attempt
to convert the Text to Value.)

In the same way, the option group has a Value, which is the value stored in
the field that the group is bound to. The individual buttons in the group
cannot be bound to any field, and it makes no sense to talk of them having a
Value. But a stand-alone option button that is not part of an option group
can be bound to a yes/no field, so it does have a Value.

Sure, it's a different mindset, but it all makes sense when you think from
the Access paradigm rather than the more generic VB paradigm.
 
Off the top of my head, I remember writing a VB app in which certain otions
within an option group needed to be disabled or enabled depending on other
settings on the form, the source of the dsata, etc. It was convenient to
refer to the members of the option group by their indices (for which I
substituted named numeric constants with names that made sense to me). I have
done trickier things, but I can't recall the details.
 
Allen, I've never needed to do this, but it is actually possible to loop
through the Controls collection of the option group.

This collection will include the label attached to the option group, the
boolean controls in the option group (whether option buttons, toggle
buttons, or check boxes), and also the labels attached to the boolean
controls. You would therefore need to skip any of the controls in the
collection where their ControlType is acLabel.

Further, the index of the items in the collection need not have any
relationship to the OptionValue of the controls. Bit of a trap, as it does
match if you added them in order.

This demonstrates how you can loop through them:

Function ShowOptionGroup(grp As OptionGroup)
Dim ctl As Control

Debug.Print "Members of option group " & grp.Name
Debug.Print "==============================="

For Each ctl In grp.Controls
If ctl.ControlType <> acLabel Then
Debug.Print ctl.OptionValue, ctl.Name
End If
Next
End Function
 
Back
Top