Adding new text boxes when a button is clicked on a loaded form

[KyleMac]

I've been unsuccessful in finding if this is a possibility. I'd like to make a button that adds a textbox to a form when you click it in form view. I had to make 39 text boxes and each also required a label and two buttons...the renaming process was quite time consuming so I was wondering if (for in the future) there is a way to code it in to automatically generate a new box when the user hits a button. I know I can access the textboxes with strings and do loops:


loop to hide all of them:

    Do While i < 40
        strL = "L" & i
        strS = "S" & i
        strC = "CS" & i
        strA = "A" & i
        Me(strL).Visible = False
        Me(strS).Visible = False
        Me(strC).Visible = False
        Me(strA).Visible = False
        i = i + 1
    Loop

edit: Now that I think of it, if there is a way to preserve the naming format when you copy/paste a control that'd work too if that is a possibility.

[June7]

I expect it is possible but if you have to regularly redesign objects then I suspect the database structure is not normalized. Allowing user to modify structure is not a good idea.

Why would another textbox be needed? What purpose would it serve?

[KyleMac]

Primary focus of the question is two fold:
1) Naming across multiple controls. 39 * 4 = 156 controls I had to manually name...this could be larger in some databases.
2) Expandability. If in the future there is a need for more than 39 I'd need to manually throw in however many more are necessary.

[June7]

Doesn't really answer my question.

Why are you adding more controls? Why should user be modifying design?

If a new textbox is needed does that mean a new field must be added to table then modify queries and reports and code as well as the form?

[KyleMac]

Because additional controls are necessary based off what is going on. As time goes on more controls are necessary (since users use the controls to access other forms). I planned on using a memo field and reading them into the memo by one textbox per line. Is there any way to preserve the naming format? Like if I have a textbox named "T1" and copy it is there any way to make that "T2"?

[ssanfu]

I agree 110% with June. This sounds like a bad design.

(since users use the controls to access other forms)

You say "users" so there are (can be) several people in the dB at the same time. So it would seem that the dB is not split, and the dB is placed on a server or a common access point and everyone opens the SAME dB.

This is a recipe for disaster. You WILL corrupt the dB - not IF, just WHEN.

If the dB IS split, then how are the changes (the added text boxes) that User A adds get to user B and user C FEs?
Say User A adds 3 text boxes and User B adds 2 text boxes.... in a split dB, no one (User C) would see the design changes in the FEs.


Maybe I don't understand, but from what you have posted, I would really suggest you stop and rethink your dB.

[June7]

These are buttons to open forms or reports? Modifying objects to add controls requires opening in Design View (or maybe Layout View) and saving the modifications. This can be done programmatically but I really don't see this as practical.

Implies a new form (or report) is built first then button must be added to a form. A well-designed db should rarely have modifications after distribution.

I do not understand the usage of memo field. And yes, code could rename the new control by incrementing the name of the original control. Just more complicated coding. How would user select T1 for copying anyway? Could not be in Form View.

You are venturing into code scenarios I would never use.

[KyleMac]

I'm certain it's not the best idea either but I was trying to find a way to avoid manually naming dozens or even hundreds of controls while allowing for future expandability. I didn't go into detail about the form because I wasn't sure how familiar people would be with the material.

ALL of what's going on:

A spell list is done. This spell list is in a table that contains all aspects of every spell. Users do not access the database simultaneously. The form has a dropdown for you to pick your class. After deciding your class you pick your character level. Based on your class and character level you're allowed so many spells and so many of each spells of each spell level. Rather than hard-coding all the text boxes in the form to only show based off "class x, level x" I wanted to code each class as a call function and based off that function textboxes would be added or taken off the form. The user uses the text boxes to add spells to their spell list and from their spell list to their prepared spell list. There are buttons next to that to clear it or transfer the spell from their "known" list to their "prepared" list. Also, they can double click any textbox to open another form and show the spell description.

The game in question here is DnD 5th edition, and as new classes are added I wanted to be able to add them in, easily. In the future, should I ever run into a scenario where I needed to rename dozens or hundreds of texboxes I was looking for a way to do that as an alternative to having users insert control boxes into the form (if that was even a possibility).

The memo field would be to save their spell list. I planned on creating a save button that would take each visible text box and throw the text into a memo field (of a table separate of the spell list table), each textbox being on a different line of the memo field, then I was going to try to read the lines back into the textboxes when a person loaded their character. This would have allowed me to avoid a table with variable field sizes.

[June7]

Doesn't matter what the database is for, principles are the same.

Expandability is probably best accommodated by making selections from combobox or listbox or form records. Each can have a filtered query as data source. Combobox and listbox can be a value list and this list can be programmatically added to or items removed.