Selecting Multiple Check boxes

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

Guest

I have a form that I want to have 5 check boxes on. I may select 1 or more
of the check boxes, and I want to store the value of which boxes are checked.

I've tried adding an option group and placing the check boxes in there, but
when I click on one box, they all become checked. If I assign them values
(1-5) and click on them, they display 1-5, but this time only one box is
checked.

How do I handle allowing for multiple check boxes? Do I use ungrouped check
boxes and then write code in the AfterUpdate event to store the value and
then use the OnCurrent event to set the values when changing records.

Does anyone have an example they can point me to or share with me.

TIA

Mark
 
If you add them to an option group (properly), you will only be able to
check one of them at a time. That's the purpose of an option group! So
if you want to be able to check any one /or more/ of them, you must not
put them in an option group.

If they all show chcked, when you check just one of them, this probably
means that you have not associated (or "bound") them with fields in the
table to which the form is bound. You should set the ControlSource
property of each checkbnox, to the name of a yes/no field in the table
to which the form is bound. You bind the form to a table by setting the
RecordSource poperty of the form, to the name of that table.

HTH,
TC
 
TC,

Thanks for your response. I'm trying to store the value though in one
field, not 5 Y/N fields. Will I have to do this programmatically?

TIA

Mark
 
But how would you store the value of /several/ checkboxes (say #s 1, 3
and 7) in /one field/?

If that's wat you're trying to do, that is not the way to go. Tell us
what you're trying to achieve from a functional viewpoint.

HTH,
TC
(off for the day)
 
I have a form that I want to have 5 check boxes on. I may select 1 or more
of the check boxes, and I want to store the value of which boxes are checked.
Click to expand...

If you are trying to store MULTIPLE values in ONE field... *you can't,
and you shouldn't*.

It sounds like you have a one-to-many or many-to-many relationship,
and need another table, using a Subform to store the one or more
values.

John W. Vinson[MVP]
 
Here's a rough look at what I'm trying to do.

You have a Prospect that your qualifying, those qualifying status include:
Status Undetermined
Qualified
Redirected
Not Qualified

The qualification status is handled through and option group and radio
buttons. This works fine, because it's just assigning a value. For
Qualified and Redirected prospect, another set of options are available, but
that too works because it's an exclusive value. Under the Not Qualified
group though, the prospect isn't a good candidate for one or more of 5
reasons.

While it's not informaion that I would probably ever query against as I'm
not interested in prospects that didn't qualify, I can see your and John's
point and will just add the four extra fields to the table. It's probably
more efficient anyway to have the wider table than building code around the
multiple states.

Thanks for the help.

Have a Happy New Year.

Mark
 
John,

As I said in my reply to TC, it's not for data that I'm going to query
against as it's just storing reasons why a prospect didn't qualify. But
after reading your and TC's posts, I've realized it's just a effective to
have 5 tiny int columns in the SQL backend rather than 1 Varchar(5) column
and manipulate the responses through code. Thanks for your response.

Have a Happy New Year.

Mark
 
Can I make a suggestion: start by describing & discussing the table
structures that you plan to use. /Then/ - and only then - start
thinking what the forms will look like.

You should design the tables to reflect the logical existence &
relationships of the data that you want to store - /ignoring/ how that
data will actually look on screens & reports. In other words, you
design the tables in a "presentation neutral" fashion. Then, having got
the table structures correct, you can use queries, forms, reports & so
on to present the data visually in the ways that you want.

This is one of the hardest things to understand, when you start to use
a database product. /First/, design the table structures. /Then/ design
the forms & reports. Do not do it the other way 'round!

Cheers,
TC
 
Back
Top