First, you are creating a dynamic report (implicitly). You are trying to do, in a constrained situation, exactly what the report wizard build does for you. You will have some pitfalls to consider and this will NEVER be trivial. However, ....
I did something vaguely like this some time ago. Since the actual code belongs to my employer, I can't post it - but I can describe it.
Basically, create a form with a bunch of unbound checkboxes. Set up the form so the boxes come up all unchecked. Create a command button to run a report based on a pre-defined query that retrieves EVERY FIELD from the table.
When you build your "drop-down" text box you can use the combo box wizard that will ask you what to do with the item you just selected from the drop-down. One option is to use it for a lookup. See how the wizard creates that code. Use it as a hint/template and use that information to define the filter for the report. Use the button wizard to create the Open Report code, then customize it. Before you open the report named by the wizard, visit the unbound checkboxes.
The next trick is, when you say "report" - do you really mean a pretty, printable report? Hoo, dogies, that is TRICKY. Not to mention that it will be visually rather ugly unless you are a REALLY good programmer who understands visual balance well enough to dynamically position things on a blank canvas. OK, so I question that it can be done easily. But how would you do it if looks were less important?
Well, start with creating a comprehensive report of all possible fields. THIS is the report you run from the button code. Remember, in this context, there is a time before the report is open during which you have access to the checkboxes that originally selected the fields you wanted to see. By having a fixed query and fixed report, you can customize whatever you want on the report because it is there on the query and report. Getting confused? Bear with me, I'm about to start making sense here. (As much as I ever make....)
OK, in the report, find the detail section. For what you described, you would only have a report header, report footer, and detail section. (OK, you COULD have a page header and page footer... but why beg for more headaches...?) On this report, remember that you pre-built it with ALL of the fields already on it. The detail section will be your canvas.
You are in design view. You can assign a Form variable to this form and access its controls by name from the .Controls collection. For each control that is visible, you are going to run code that either eliminates the control or jams the control and its associated label to a convenient spot.
What I'm going to suggest will take a report with EVERYTHING on it and leave only what was selected. Sort of like the scuptor who was asked, "How did you make this stone statue of a dolphin?" To which he replied, "I started with a cube of stone and removed everything that didn't look like a dolphin."
In this situation, you are going to take advantage of the properties of label boxes and text boxes. All rectangular controls have four properties - .TOP, .LEFT, .HEIGHT, and .WIDTH - in units called TWIPS. The detail section of the report ALSO has these four properties. So what you do is, you have a couple of LONG integer variables to track where you last put something. One for "RIGHT" and one for "TOP". Start the BOTTOM keeper at the .HEIGHT of the detail section. Start both of these at zero, which is the upper left corner of the detail section of your report.
As you step through the checkboxes for the fields you want, if the box is NOT checked, you make the label and the text box not visible (property .VISIBLE = NO ) and you move it to the upper left corner of the detail section ( .TOP = 0, .LEFT = 0 ). Since it is invisible, it doesn't matter how many of these you have. BUT...
For each selected field, you reset the .TOP and .LEFT properties for the label and text box, (.LEFT of each box = the RIGHT value you were keeping, .TOP of the label to the TOP you were keeping, .TOP of the textbox to the TOP you were keeping plus the height of the label box. Then add the text box .WIDTH to the variable that tracks the RIGHT edge of the last allocated box.
Obvioiusly, before you allocate any slots on the report, you set the RIGHT edge to 0. OK, so you allocate these things until you reach a field that would go off the edge of the detail section (.LEFT + .WIDTH of control > .WIDTH of detail section.) So at that point, you update your TOP edge to 1 twip below the .TOP + .HEIGHT of the text box you just allocated. Reset the RIGHT edge to 0 again. Do that until you are out of fields to select or deselect. (Technically, hide or reveal...)
A neat finishing touch: The bottom of the last control you allocated visibly can become the bottom of the detail section, which ALSO has a .height property you can adjust. Making the bottom of the report flush with the lowest text box.
When you are done, you have a report. Now save the report (it is a DoCmd thing) and then bring it up in normal mode rather than design mode.
The down side? Unless you very carefully re-use report names, you will quickly overrun the capacity of Access to remember all of these reports that you build. Perhaps... you could use a FE/BE situation with each user having his/her own Front End. Then each user could have one "custom" report that contains everything as described earlier. They can customize this report to a fare-thee-well - but only one customization at a time. They have to print it to preserve it because the next time they customize a report, guess which one gets clobbered?
