TC
Now we are getting somewhere!
If you go back over my messages, I've used the following names to mean:
"OptionButton" => the control used to specify which option is selected
"Frame" => the group control that contains the set of OptionButtons.
Now, I agree that testing the value of OptionButton to see if that option
has been selected won't work. For that function, one must test the value of
the Frame Control, for that is the control whose value changes when an
OptionButton changes state. In earlier days, these were called "Radio
Buttons". You could only push one radio button at a time, and if pressed,
any other button pushed would pop out. The radio (Frame) would switch to
the station (Frame.Value) selected.
Additionally, OptionButton.OptionValue contains the value (radio station)
assigned to that button. When delivered (designed), each option button was
set to a specific station (value), BUT the new owner (application) had the
option to change the station (value) assigned to each button, as often as
he/she liked, whenever they liked, even while traveling down the highway
(dynamically).
One could listen to the radio station (test the value of the option group
control (Frame)) to determine which radio button had been pushed.
I believe we are now in agreement, and probably always have been. Such is
the ambiguity if the English language. If we in fact, are not in agreement,
I have a tiny demo database that demonstrates my position. Would love to
send it to you, but I don't know how big a file the newsgroup will accept.
However, the code module for my form follows. The control group is Frame0.
The controls are Option2 and Option3.
Design time values are Option2 = 1, Option3=2.
-----------------cut line--------------------------
Option Compare Database
Private Sub Form_Open(Cancel As Integer)
Option3.OptionValue = 5
End Sub
Private Sub Frame0_AfterUpdate()
MsgBox "Option3 test for 5 returns " & (Option3.OptionValue = 5)
'Returns TRUE
MsgBox "Frame0 test for five returns " & (Frame0.Value = 5)
'Returns TRUE
End Sub
Private Sub Frame0_Click()
MsgBox "Value is " & Frame0.Value 'Returns either 1 or 5
End Sub
-----------------cut line--------------------------
If running this code on A97 works differently, I submit that the two Access
versions behave differently. This leads to a discussion of which coding
method best preserves the business logic of the application across the
various existing (and future) Microsoft product migrations. Failure to
manage these selections correctly, leads one into either a career of program
maintenance over one of new development, or, a continual need to update
one's resume. We used to talk about paying programmers a royalty on
application programs that ran without the need for maintenance. Wouldn't
that be fun?
-Jim
TC said:
Hi Jim
I use A97, but I'm sure it works the same in all versions.
Perhaps we are talking at cross-purposes due to an excess of xmas libations?
All that I am saying, is this. A test like the following will never serve to
determine what option is currently selected in an option group control:
If me![option_control_name] = any_constant then ...
(option_control_name is the name of one control within the group - not the
name of the group control itself.)
This is because a test of that kind will >always< be true, or >always< be
false, depending on design-time selections. It will never produce different
results depending on what option is selected at runtime. If you disagree
with that, you'll need to show me some actual code to support your
contention!
Cheers!
TC
Jim Shaw said:
TC;
We must be using different versions of Access. I'm using Microsoft's
Access/XP (2002). I have all service packs and upgrades installed also.
Which version are you using?
I did as you suggested-- the results prove my point, not yours.
With a design time specification of 1 for the option value and a run time
setting of the value to 5,
the test (Option1.OptionValue = 1) >always< returns false and
(Option1.OptionValue =5) returns true. I also got the same result testing
the frame's value. My logic works as I stated.
What say you now??
Seasons Greetings
Jim
with assigned
the
5
lines
of
code
that I showed in my post. It >is< safer (from a software
development
viewpoint) because it >does not< rely on hard-coding the
optionvalues
of
the
option group controls. Read it again!
TC
I think your way is not safer for it will take more code to
analyze
which
option was selected by interrogating each one of them;
assuming
that's
even
possible.
For self documentation of the case statement, declare a
meaningful
option
group control name and constants for the values returned.:
Constant SINGLE = 1
Constant MARRIED = 2
etc.
These can be tucked away in a separate module if you
like.
I
put
mine
in
"modEnum" myself.
Select case MaritalStatus
case SINGLE
case MARRIED
case UNDECIDED
etc.
Yields tight, self documenting code that is not prone to
software
bugs.
-Jim Shaw
I prefer a solution that does not need any knowledge
of
the
current
option
values.
select case me![grpWhatever]
case me![optThis].optionvalue
case me![optThat].optionvalue
etc.
end select
where optThis, optThat etc. are the controls wihin the
option
group.
This is safer (IMO) and more "self documenting" than using
case
1,
case
2,
case 3 etc.
HTH,
TC
