Creating an Option Group Programmatically

Amless

New member
Local time
Today, 17:11
Joined
Feb 18, 2009
Messages
3
Trust me I have looked through all my manuals and having been browsing the 'net for quite a while to get help with this and haven't found anything.

I am using Microsoft Office 2003 with Visual Basic 6.5 and need to learn how to write the code which will create an option group an name the buttons based on values in a table.

For example, I have developed a database to tally the scores/results for a Track & Field day. The program is good to go, but if the organizers decide to add or delete some of the events this will require some redeveloping. So for an option group that I have where users may select an event, I would like to know how to write the code to create this option group programmatically.
 
I am using Microsoft Office 2003 with Visual Basic 6.5
So does does mean that the front end is in VB 6.5 with an Access back end?

After you make the changes to the design, how will you recompile the EXE and get it deployed to the workstations? You can not make design change at runtime in a compiled VB app. Are you wanting to do this at designtime before compiling a new EXE?


If you really mean with Acess 2003 and VBA:

To do what you are asking, you will have to open the form in design mode and use VBA code to edit the form. The problem with this is that if this is that you must use an MDB/ACCDB format. It is common to use an MDE/ACCDE format to deploy a front end into production. The problem with this is that you can not use the design mode for in an n MDE/ACCDE format. This is probably why you are having a problem founding anything about how to do this.

IMHO, it would be a better design to a combo box or list box for this.Use table to store the list of event names. This is a common method with Access. This way you will not have to make any design changes when an event is added.
 
Thank you for your response.

So does does mean that the front end is in VB 6.5 with an Access back end?
I am using Microsoft Access 2003 to create the tables, queries, forms and reports, but whenever I work with codes that opens Visual Basic 6.5.

After you make the changes to the design, how will you recompile the EXE and get it deployed to the workstations? You can not make design change at runtime in a compiled VB app. Are you wanting to do this at designtime before compiling a new EXE?
I'm just a small-time software developer and I haven't worked much with "compiling a new EXE". Last year was the first time we used the program and I was the one running it because I knew where the forms and reports were. I am now trying to make it more user-friendly which means I want people who don't have any programming knowledge to be able to use the software.

I also don't develop with a front end and back end. (Although for another database I need to learn how to do this.)


IMHO, it would be a better design to a combo box or list box for this.Use table to store the list of event names. This is a common method with Access. This way you will not have to make any design changes when an event is added.
I am quite comfortable working with combo boxes and list boxes and yes, it would work here, but I have another application for this feature which involves a lot of data entry so I'm trying to do it with as few clicks as possible.
 
I am using Microsoft Access 2003 to create the tables, queries, forms and reports, but whenever I work with codes that opens Visual Basic 6.5.
It is true that the editor that opens is the same one used by VB, but it is not the same as Visual Basic 6.5. It is just the same editor. You are actually editing VBA code from Access, not VB code for Visual Basic 6.x.


I am quite comfortable working with combo boxes and list boxes and yes, it would work here, but I have another application for this feature which involves a lot of data entry so I'm trying to do it with as few clicks as possible.
Then you probably do want to use a combo box. All of my user that can type really prefer a combo box where they can type and not have to "clicking" since it is so much faster tio use the keyboard than taking the time to reach for the mouse.
 

Users who are viewing this thread

Back
Top Bottom