Expanding/Contracting forms (newbie question)

[Maury Markowitz]

I have a complex form that contains a LOT of logic driving its state. It's
used for ticketting trades (stocks, etc.). In 80% of the cases the form is
used it is quite "simple", they place an order for a stock, receive it as a
single fill, and place it in a single bank account.

In 20% of the cases, they place the result of the fills into TWO bank
accounts.

In a separate (orthogonal) 20% of the cases, they get two or more fills.

What I would like to avoid is poluting the form for the 80% of the cases to
be able to handle the other 20%. I could make two separate forms, but that
means two code bases and UI's to keep in sync.

A better solution would be to include optional areas of the form that appear
or disappear on request. For instance, if they receive more than one fill,
the single line with fill details will be replaced with a multi-row subform.

The logic I can do, here's my question:

Is there some way to allow the form to adjust its sizing based on the
visible contents? The form is VERY complex, so if I have to code in moves to
the objects, things will get VERY complex. What I would prefer is something
that lays out the form for me. Is this something the forms system can do?

Alternately I'm open to any suggestions. One thought is to make four
versions of the form, one showing neither sub-editor, one with one and not
the other, and so on. That way I have only four possible sizes for the form
overall, and can copy in the "whole whack" of items already in the right
position. However this really complicates the logic, either because I have to
have "real" subforms, or alternately four copies of the same object with
different names.

Finally, is it possible to place a bunch of objects into some sort of group
and refer to them as a whole? For instance, could I put everything below
these optional sections into a named group, and then say
"ButtonsGroup.top=xxx" and move everything in it? That would be a fine
solution, if it's possible.

Maury

 

[Pat Hartman\(MVP\)]

Forms cannot shrink and grow as reports do. Try laying out the form with
tab pages. That way, the users only have to go to the other pages if they
need to. And finally, look into class modules. You can create separate
class modules that will work with multiple forms so you only have to
maintain a single code base. I haven't had occasion to use them so I can't
give you specific advice but I think you just "call" the class module "with
events" when a form opens and all event processing is handled by the class
module. You can also have code embedded in the form itself but I'm not sure
which code is executed first or if one prevents the other from being
executed.

 

[Maury Markowitz]

Forms cannot shrink and grow as reports do. Try laying out the form with
tab pages. That way, the users only have to go to the other pages if they
need to.

I've tried these in the past, but I seem to recall them not doing what you
really need. IE, each tab is still part of a single form's recordset.
Actually this might not be an issue if I use subforms?