Create Check Boxes/Option buttons/Option Group using VBA

[hewstone999]

I’m really stuck on how to create: Check Boxes/Option button/Option Group in VBA.

Could someone help on either all of them or some of them please?

Thanks

Richard

 

[chergh]

Take a look at the vba help files for the checkbox, option button and option group objects. Once you have these help files open you can then look at the methods available to these objects, to add these objects programatically you will need an add item method, if there is no method that allows you to add an item then you won't be able to add these using VBA.

 

[gemma-the-husky]

you dont create the boxes in vba, but they have events

put an option group on your form, and the wizard will let you fill it with option buttons. each button has a value, 1,2,3 etc, and whichever one you click is returned as the value of the option group as a whole

typically you use the afterupdate event of the group (ie the rectangle itself) to manage the group, and NOT the buttons within the group

 

[matjung]

In general you can add controls via VBA.
Use Application.CreateControl for this job.

For parent you have to choose the name of the OptionGroup where you want to place the OptionButton
Sample:
Set o = Application.CreateControl(frm.Name, acOptionGroup, acDetail, , , x, y, w, h)

 

[Mr. B]

Just one word of caution:

Programatically creating controls is problematic in that there is a limit of 754 controls that can be added to any form over the life of that form. So, as you or your users use the application, you will eventually hit the wall by having add too many controls to your form.

I normally create all of the controls I need on my form and then use come method for making them visible or not visible based on the conditions created as the user uses the form.

 

[mdlueck]

... there is a limit of 754 controls that can be added to any form over the life of that form.

Really?!!?!?

I would have thought Microsoft had learned their lesson from "Max Break Points" (MaxBPS=) in Windows 3.1!!! http://books.google.com/books?id=_D...a=X&ei=_OjwTvm3BMrvgge93bn8AQ&ved=0CCIQ6AEwAA Sounds to me like a similar scenario. That had a maximum value of 768, so this limit is lower than that limit.

I think I will move a bit down on my "would like to try" list building code to build UI widgets. Thanks for the heads up, Mr. B.

 

[boblarson]

Really?!!?!?

Yes, really.

I would have thought Microsoft had learned their lesson from "Max Break Points" (MaxBPS=) in Windows 3.1!!! http://books.google.com/books?id=_D...a=X&ei=_OjwTvm3BMrvgge93bn8AQ&ved=0CCIQ6AEwAA Sounds to me like a similar scenario. That had a maximum value of 768, so this limit is lower than that limit.

Nothing is ever unlimited, at least most things, in any Windows program. And to think that an obscure issue such as MaxBPS would be known throughout Microsoft (that is a very large corporation with thousands of employees) and that it would affect all design work on every program for every item is a little much to expect.


(oh, but thanks for the link - that was cool to look at some of the other articles and advertisements as well. My how have things changed)

 

[Pat Hartman]

If you must open any object in design view, you will NOT be able to distribute the application as an .mde or .accde and you will NOT be able to use the Access Runtime engine to run it. You will always need to distribute an .mdb or .accdb and the user will always need the full retail version of Access installed to run your application. And besides, this is not the Access way. If you use a continuous subform, you won't need code at all. Using the tools Access gives you for rapid application development will result in less code, less testing, more stability, etc. Subforms are "infinately" expandable. That is the technique you need to employ.