D
David Mueller
I'm trying to decide just how bad runtime design is. Most opinions seem to
steer clear of adding controls, events, etc at runtime. Instead, y'all
advocate keeping controls on the form and hiding them as necessary.
In my application (which will not be an MDE) , each user session builds a
new form - from scratch. Once the form is built, there are no design
changes. And when the user is done the form object is deleted.
Troubleshooting may be more difficult with a form that only exists at
runtime. OTOH, documenting and tracking unused controls (or not having
enough controls, or having too many controls) is no picnic.
I think my disposible form approach mitigates the problems I've seen
described with designing/redesigning the same form object over and over, with
the exception of some bloating. A 100% table-driven form wizard is very
attractive as the business needs are demanding an unthinkable amount of
flexibility.
Your feedback is appreciated.
Thanks
David
steer clear of adding controls, events, etc at runtime. Instead, y'all
advocate keeping controls on the form and hiding them as necessary.
In my application (which will not be an MDE) , each user session builds a
new form - from scratch. Once the form is built, there are no design
changes. And when the user is done the form object is deleted.
Troubleshooting may be more difficult with a form that only exists at
runtime. OTOH, documenting and tracking unused controls (or not having
enough controls, or having too many controls) is no picnic.
I think my disposible form approach mitigates the problems I've seen
described with designing/redesigning the same form object over and over, with
the exception of some bloating. A 100% table-driven form wizard is very
attractive as the business needs are demanding an unthinkable amount of
flexibility.
Your feedback is appreciated.
Thanks
David