Well, actually you can, with Conditional Formatting (in 2002 and
later).
Certain kinds of things you can do (and it was introduced in 2000,
not 2002), but things like hiding and showing controls and changing
rowsources of combo boxes don't work.
say WHAT!?
David, you just destroyed fifteen years of my database work. I
don't think I've ever implemented a database without several
continuous forms routinely used for data entry and editing!
Could you explain your rationale? You've certainly raised my
curiosity!
I think it's user unfriendly to force editing in a continuous form,
except for a few types of entities, such as an invoice.
There are a number reasons why I have concluded this:
1. my users have never felt comfortable editing in subforms.
2. I have consistently run into problems with conditional display of
controls and most importantly, conditional assignment of rowsources
to combo boxes.
Because of that, I've always almost implemented a read-only
continuous form as a super-listbox (i.e., with much better features
than a mere listbox) from which the user selects a record, and then
the record is loaded into the detail form. It's very easy to do this
by using the PK of the continuous subform as the link criteria for
the detail form.
The place where it gets tricky is adding new records, but I consider
this a feature and not a drawback, because I long ago gave up on
trying to use the same form both for adding new records and for
editing already-created records. First off, if you have any required
fields, it's easy for the user to get stuck in a record. Secondly,
cancelling the add requires deleting the record, and you lose an
Autonumber. Now, that's no disaster, as Autonumbers don't have any
meaning, but I prefer to not load a multi-user shared back end with
having to add an Autonumber and then end up deleting.
With an unbound dialog form for adding new records, you can collect
the required fields and only add the record when you have all the
right data. And cancelling does nothing to the underlying data
table. Also, it's an excellent place to check for possible
duplicates because you then don't load the database with the locks
and error conditions that come from trying to insert a record that
violates a unique index.
This has been my SOP for nearly 10 years, and I've found it much
less work than trying to get editable continuous forms to do all the
things that are needed in my apps.