Solved Control a Form field through a ComboBox? (1 Viewer)

[KM88]

Hi all,

Sorry if this is a silly question or I've worded it poorly, googling hasn't provided me many results and at this point I might be overthinking it...

Basically I have this template type form where a each text field is accompanied by a checkbox beside it, if the user checks the checkbox then that text field will be included in the template, if they click it off, I will exclude it. The fields can also be filled out to store default text. (The template is saved and when a user selects a created template the included questions will show up on the form dynamically)

Right now I have each field designated to a column so a single record is created in the form and each text field value is stored in that row. I have created checkbox columns in the table as well but I can't figure out how to associate them with the text field column other than hard coding which would be a nightmare.

Should I be nixing having this controlled via a table? Should I set the control source of the textbox to be an expression instead of a column so I can have a value column with the checkbox column (not sure how I'd set the control source exactly or if I can even do that)? Or should I be creating multiple tables and trying to relate the values? The latter sounds like the correct route to go but I'm struggling in the working concept of it.

Again, sorry, I'm a little new to access and to this forum in general so any insight would be appreciated. Thanks so much in advance to anyone who can help.

 

[theDBguy]

Hi. Welcome to AWF!

The true power of a relational database resides in a proper table structure. If you describe the business model of your database and show us your table structure, we might be able to advice you on a proper course of action.

 

[jdraw]

Welcome to AWF, KM88!

 

[GPGeorge]

As a general rule, procedures that give users control over creating or modifying tables, or even creating or modifying forms or reports, tend to be problems in waiting.

For that reason, I'm reluctant to support an approach that, apparently, would result in dynamically adding fields to a form's recordsource and then creating controls to which those fields would be bound.

However, as theDBGuy said, we really ought to start at the beginning. Why do you want to go down this path? What's the end game? Who will use it? What will they produce with it?

The tables are the foundation, so we have to start with good table design.

Thanks for providing sufficient details to formulate suggestions.

 

[KM88]

Thanks so much for the warm welcome and the replies!

So basically the users have a standard template they're meant to fill out but they also require some prebuilt templates of the template that could not include certain fields and also can prefill fields with information. That's kind of why I started to put together this template maintenance form with checkboxes beside fields. It's bound to a local table that when they push save pushes the information into a backend template table for storage. Maybe I'm going about it the wrong way in my thought processes.

The local table is just a one record table at the moment where the columns are bound to the form field values, which again, is probably not the best approach but I'm too sure what would be. I'll try and come up with something better but I appreciate the advice so far!

 

[oleronesoftwares]

Welcome @KM88

 

[Pat Hartman]

Welcome
You haven't given us any more information. All we know is what you decided would be the solution. It is important to describe the business problem. Why do new columns appear out of no where? I'm with George on this one. Access is not Excel. We do NOT allow users to create new forms or fields or reports. PERIOD>

 

[KM88]

Hi Pat, thanks for the reply, yeah I'm sorry I'm not great at explaining the issue, not very fluent. I didn't really want columns to appear out of nowhere.

I was kind of hoping there was just a elegant solution I could implement where someone could load up the standard template in a template design type form, type in information in fields that they know what the value will be, deactivate fields they don't want and then save that template. Then in the main form instead of using the standard template they could load in that template they saved that had the prefilled information and the unnecessary questions removed.

Again, apologies for my poor explanation/lack of information, I appreciate all of the input.

 

[Pat Hartman]

You are assuming that we know what a "template" is. You are not using the word in some generic sense. You are using it as if it were some type of business entity.

Forms don't save data. Tables save data. That is the other confusing aspect of your question. If you have a table that has a bunch of fields but some are relevant for some tasks and others are relevant for others, you probably have a design flaw, But, assuming you don't, You would need some way of identifying template1 vs template2. You would need two separate copies of the main form. One bound to the production data and the second bound to the template table. You use the template process to save common sets of data. Then in the main form, when adding a new record, the first step would be to use a combo to pick a template. Your code then copies all the columns from the template table to the production table and you can then change defaults copied from a template if necessary and add other data as necessary.

Does that describe what you are looking for?

Before you go down this road, you should probably post your database so we can look at the schema and make recommendations that might eliminate the need for this process.