Continuous Forms, What are they used for?

  • Thread starter Thread starter HKComputer
  • Start date Start date
H

HKComputer

What value do continuous forms have? I use datasheet for views like
this. What advantages do I gain with continuous forms? Can someone
give an example of where you need/use them?
 
Have you ever tried to place a line or command button on a datasheet form?
Datasheet also won't allow column titles with two or more lines:
First
Name

You also have more options with colors and other formatting with continuous
forms.
 
Forms (continuous or otherwise) will automatically take care
of row locking (if that is set in options) in a multi user
situation.

A continuous form will let you design your own look and feel
(user interface).

A form exposes all the events you need to trigger
vba/macros, place buttons to do things and all that.

If you are the only person who uses the application and are
intimately familiar with the data there may be no gain for
you. Forms are of most use to limit user errors, make an
application easier to use (more friendly if you like) and to
make manipulating data less techy for the technophobic or
less skilled.

--
Nick Coe (UK)
http://www.alphacos.co.uk/ AccHelp + pAnimal
http://www.mrcomputersltd.com/ Repairs Upgrades

In
HKComputer typed:
 
Hey, I like your informative page, Mr. Kallal. I must say I can now
see the use of continuous forms better than I could before.

I didn't explain myself well enough in my question. I said I use
datasheet view. In truth, I do not allow datasheet view directly to
the table. I always use a form in datasheet view, usually a subform in
fact which allows me to put controls on the form that interact with the
subform.

The comments y'all about the necessity of forms were in place. I
always try to remove the user from the table. In fact, recently I have
taken to removing validation and "Required - Yes" rules from the table
and enforcing the above stated on a form level. (On another note, I
don't understand why Microsoft gives options on table design that are
not ODBC compliant or are not upsizeable, (now referring to lookup
fields in tables)).

Would/could I use continuous forms, with the proper filters, where the
user needs to select items that showing for reorder? By using the
checkbox, the user could specify which items get transferred to an
order?!?
 
Microsoft gives options on table design that are
not ODBC compliant or are not upsizeable, (now referring to lookup
fields in tables)).

Well, the forms, or code don't upsize either. I mean, we could limit the
product to forcing you to write 100% c++ code by hand to build a form. That
way, you could move the forms to other platforms...but then again likely few
would use the product. Those lookup features are loved by beginner
developers. Experience will teach users that the table lookup feature is a
pain in the neck. It is kind of difficult to take away a feature that makes
things easy..but are not necessary the best design choice...

note #2 in the following list that warns about using lookup fields...

Would/could I use continuous forms, with the proper filters, where the
user needs to select items that showing for reorder? By using the
checkbox, the user could specify which items get transferred to an
order?!?
Click to expand...

Yes...your only decision is do you use a bound check box column for the user
to select. If the list is short, then of course a listbox is better, since
it allows a multi-select ability. So, if the "list" is only for selection,
then perhaps a listbox would be better (however, as my article
shows...listbox don't have combo box..or check box controls).

So, for selecting, you simply add another column (a yes/no field in the
table). If you do NOT want to add a check box, then you can do this with
some tricky code...I have a multi-select example here that uses a un-bound
check box....

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html
 
Back
Top