66 Options

  • Thread starter Thread starter Jim Shaw
  • Start date Start date
J

Jim Shaw

BlankI'm generating a report that has a section consisting of 66 Check
Boxes. For any given data row in the underlying table, only one of the 66
options is checked. Ideally, this would be handled by defining an Option
Group driven by a single data element in the underlying data table's rows.
Unfortunately, Access 2002 only allows 20 options in a group. There is no
intuitively obvious sub-grouping of these 66 options that fit into the 20
option restriction. My client will not allow me to replace all of the check
boxes with a single text box on the report.

Is there a better way of dealing with this many options in VBA other than 66
Case or elseif statements?

Thanks
-Jim
 
Jim said:
BlankI'm generating a report that has a section consisting of 66 Check
Boxes. For any given data row in the underlying table, only one of the 66
options is checked. Ideally, this would be handled by defining an Option
Group driven by a single data element in the underlying data table's rows.
Unfortunately, Access 2002 only allows 20 options in a group. There is no
intuitively obvious sub-grouping of these 66 options that fit into the 20
option restriction. My client will not allow me to replace all of the check
boxes with a single text box on the report.

Is there a better way of dealing with this many options in VBA other than 66
Case or elseif statements?
Click to expand...


Sorry Jim, but this question doesn't even start to give me a
clue what you mean by "dealing with these check boxes".
Since this is the reports newsgroup, I might make some
guesses, but it would be better if you just explained what
you're trying to do with the check boxes.

I've never run into a limit on an option group so I don't
know where you got the idea that an option group is limited
to 20 options, maybe you were using a wizard with that
limit? Besides, I can't see how "dealing with these check
boxes" could be solved by using an option group.

I will take a guess that you should have only one field in
the table that is bound to your data entry form's option
group with all 66 check boxes. I would also have a table
that has at least two fields, the option value and its
description. Think about it, it may simplify the issue.
 
Thanks Marsh, you got me going again.

My report is a one page report documenting a single employee's separation
from the company. There is one page per record in the underlying data
table. One data element contains a value 1 - 66 that indicates the reason
for the separation. The report simulates an old manual form used by 199
other divisions of a corporation into which terminations are reported.
Corporate wants all forms from all divisions to be the same. My client is
the only division that is being automated.

I was creating this report in "Design View" using the Option Group control
(which I now understand to be a wizard), entering options when I ran into
the 20 options limit. After a bit of experimenting using your input, I
discovered that I could add more options to the group myself simply by
placing check boxes in the option group frame. Nice!

As for "dealing with these check boxes", I was referring to a need to write
66 nearly identical lines of code to get the appropriate check box checked.
Use of the option group on the report greatly simplifies this task.

I do have a table with the option descriptions. I use it to populate a 2
column list box on the input data form. The columns provide the description
and the check box value. This makes it easy to specify the termination
reason.

But from your comment, having the description in a table might make the
development of the report easier. How so? I'm not sure what you were
thinking other than to use the description to dynamically populate the 66
check box labels?

Thanks
Jim
 
Jim said:
Thanks Marsh, you got me going again.

My report is a one page report documenting a single employee's separation
from the company. There is one page per record in the underlying data
table. One data element contains a value 1 - 66 that indicates the reason
for the separation. The report simulates an old manual form used by 199
other divisions of a corporation into which terminations are reported.
Corporate wants all forms from all divisions to be the same. My client is
the only division that is being automated.

I was creating this report in "Design View" using the Option Group control
(which I now understand to be a wizard), entering options when I ran into
the 20 options limit. After a bit of experimenting using your input, I
discovered that I could add more options to the group myself simply by
placing check boxes in the option group frame. Nice!

As for "dealing with these check boxes", I was referring to a need to write
66 nearly identical lines of code to get the appropriate check box checked.
Use of the option group on the report greatly simplifies this task.

I do have a table with the option descriptions. I use it to populate a 2
column list box on the input data form. The columns provide the description
and the check box value. This makes it easy to specify the termination
reason.

But from your comment, having the description in a table might make the
development of the report easier. How so? I'm not sure what you were
thinking other than to use the description to dynamically populate the 66
check box labels?
Click to expand...


I was guessing that the report was only supposed to display
a single value with the description. But if you're required
to display all 66 check boxes, it wouldn't have to come into
play.

Other than the tediousness of creating the option group,
does that solve your problem?

As an advanced topic that's probably beyond this current
issue, you could program the report's Open event to use the
table to fill in the check box labels with the description.
But let's not get into side issues until the report's basic
functionality is squared away.
 
Marsh
You solved my problem...Thanks
Yes, I must show all 66 check boxes on the form.

I'm also implementing the Open event to load descriptions from a table.
That way, if corporate changes the descriptions, the user stands a chance to
make the changes themselves via a table update. Doesn't help if they go to
a 67th option though.

Thanks again.
Jim

..
 
Back
Top