Adding Checkbox Dynamically at RunTime

  • Thread starter Thread starter Tim
  • Start date Start date
T

Tim

Hi

I want to be able to add checkboxes dynamically at run time. The labels for
the checkboxes will come from a table in the database. Then the user will
check the items that they are interested in. These items will then
constitute a report.

Can you give me some code examples or point me to a web site with the
answers?

Thanks

Tim Cowan
 
There is a limit to the number of controls that can be created for a report
or form..... if you programmatically create controls, you'll eventually
reach that limit.

Instead, put on the form or report all the controls that you think you'll
need/want, and make them invisible. Then have your code make them visible if
you want to use those controls for a particular session. You can
programmatically set the caption of the label that is attached to the
controls too so you then can insert the names of fields that you want to
show.
 
Hi

I want to be able to add checkboxes dynamically at run time. The labels for
the checkboxes will come from a table in the database. Then the user will
check the items that they are interested in. These items will then
constitute a report.

Can you give me some code examples or point me to a web site with the
answers?

Thanks

Tim Cowan

If you're talking about adding checkbox *fields* - yes/no fields - to
a Table... DON'T.

Would it not be possible to have a many-to-many resolver table with
your main table's ID, the Label from the labels table, and a yes/no
field? The user could go down the list in a continuous subform and
check records, rather than adding new controls or new fields.
 
Hi John

I have created software that tracks expenses. These expenses are assigned to
categories that the user can create. (Groceries, gas, entertainment, etc.)
I want the user to be able to select which items they want to see on the
report. The checkboxes would have the label groceries, gas, entertainment
etc.

One of the reasons I wanted to do it dynamically is that the user has the
ability to add/remove categories. In this scenario I could not tell in
advance how many categories there would be so I would have to have a dynamic
method of creating the check boxes.

If it is not possible with Access then I will use another method. It would
be easier if the categories were known in advance and then I could simply
design the form ahead of time, but that does not offer the most flexibility
for the user.

Still have the same advice?

Thanks

Tim
 
Hi John

I have created software that tracks expenses. These expenses are assigned to
categories that the user can create. (Groceries, gas, entertainment, etc.)
I want the user to be able to select which items they want to see on the
report. The checkboxes would have the label groceries, gas, entertainment
etc.

One of the reasons I wanted to do it dynamically is that the user has the
ability to add/remove categories. In this scenario I could not tell in
advance how many categories there would be so I would have to have a dynamic
method of creating the check boxes.

If it is not possible with Access then I will use another method. It would
be easier if the categories were known in advance and then I could simply
design the form ahead of time, but that does not offer the most flexibility
for the user.

My advice holds even more strongly. Use a Subform with a combo box
based on the list of categories; use the NotInList event of the
category combo box to allow the user to add new categories. This
provides *total* flexibility; the user can add or (with an appropriate
maintenance form) delete or edit categories at will.

Changing your table or form design at a user's whim is a steep and
rocky road to catastrophe! Users should be able to change DATA, not
design, except in truly exceptional circumstances.
 
Thanks John, hear you loud and clear.

Tim

John Vinson said:
My advice holds even more strongly. Use a Subform with a combo box
based on the list of categories; use the NotInList event of the
category combo box to allow the user to add new categories. This
provides *total* flexibility; the user can add or (with an appropriate
maintenance form) delete or edit categories at will.

Changing your table or form design at a user's whim is a steep and
rocky road to catastrophe! Users should be able to change DATA, not
design, except in truly exceptional circumstances.
 
Tim

I hear John's warning, and I agree with it. I think we can give you a better resolution based on your earlier note better describing the issue

Use a multi-select list box instead. The items in the list can change dynamically. The user can select one or more expenses he/she wants to see in the report. It takes away the issues you faced programmatically modifiying the form's design, but gives you the flexibility (I think) you were after

Regards
Adam

-- That's it kids! Take my message to the streets!
 
Back
Top