RunTime forms with modules...

[TKO]

I would prefer make the app executable, but can not create runtime forms with
modules in an .mde file. the forms created at runtime are based on
fieldnames in tables, these are not known at design time. Has anyone
attempted to implement this sort of runtime functionality, to create forms
with modules from an executable (.mde)

 

[Marshall Barton]

I would prefer make the app executable, but can not create runtime forms with
modules in an .mde file. the forms created at runtime are based on
fieldnames in tables, these are not known at design time. Has anyone
attempted to implement this sort of runtime functionality, to create forms
with modules from an executable (.mde)

The trick to this kind of thing is to **never** create a
form or control at runtime.

At design time, create a form with plenty of invisible text
boxes. Then at runtime, make a text box visible, assign a
field name to its ControlSource and maybe even set its Top,
Left, etc properties as needed. This approach is actually
easier than creating a form and its controls completely in
code and it avoides all the bloat and corruption issues that
might occur with runtime creation.

Hint, name the controls with a common prefix and a
sequential, numerical suffix (e.g. txt1, txt2, etc). Use a
different prefix each control in a group of controls. This
way you can use a trivial allocation scheme when you need
another control:
Me("txt" & intNext).Visible = True
Me("txt" & intNext).ControlSource = strfieldname
Me("lbl" & intNext).Visible = True
. . .
intNext = intNext + 1

 

[TKO]

Interesting I came up with the same solution today at my desk.

I realized that what I was trying to do was mix design time operation with
runtime operation and the IDE opening at run time presented the symptom of my
percieved problem and that in fact perhaps my problem is not an anomoly of
the Access software but rather in the manner in which I was attempting to use
it.

However, I thought it would be nice to be able to selectively make any
Modules executable, while still being able to allow design time operations of
forms with modules at run time.

You see, the form that I am creating is based on the fields in a table, and
it would be convenient to be able to allow the end user to be able to
customize their application to meet their own needs in order to avoid
additional development effort on my part, for example by adding or removing
fields on a table, so the next time the application was run the form would
accurately reflect the modified table. Theoretically then, the form with
module would be created at run time based on the fields of the table, then
destroyed after it is used.

The users could modify the table as needed by adding or removing fields at
run time and it would not require any additional effort on my part and make
the product of my effort more generic that could appeal to a larger number of
users while minimizing my own effort.

But this is not possible, hense, the soulution that you suggested is the
correct approach.