Form Question - How to Avoid Too Many!

[Johnny M]

I have several databases where I have one form to add a new record and one form
to edit an existing record. I use unbound forms and class modules most of the
time.

What I would like to do is have one form that handles both adding a new record
to the database and editing the same type of record. The form would be altered
in the load event to change whatever needs to be changed to show the form
in an "Add" mode vs. and "Edit" mode (I guess???).

Does anyone have any ideas/experience on this? I'm sure in an truly OOP
environment this is childs play/standard operating procedure. Please let me
know what you think.

Johnny

[John Winterbottom]

"Johnny M" <jm*******@gmai l.com> wrote in message
news:55******** *************** ***@posting.goo gle.com...

I have several databases where I have one form to add a new record and one
form
to edit an existing record. I use unbound forms and class modules most of
the
time.

What I would like to do is have one form that handles both adding a new
record
to the database and editing the same type of record. The form would be
altered
in the load event to change whatever needs to be changed to show the form
in an "Add" mode vs. and "Edit" mode (I guess???).

Does anyone have any ideas/experience on this? I'm sure in an truly OOP
environment this is childs play/standard operating procedure. Please let
me
know what you think.

When you open the form, use the DataMode argument to open in Add or Edit
mode, depending on whether you want to add a new record or edit an existing
one. If you're editing an existing record, pass the PK value of the record
in the OpenArgs argument and have your editing form filter the underlying
data source to find this record.

[Bas Cost Budde]

Johnny M wrote:

I have several databases where I have one form to add a new record and one form
to edit an existing record. I use unbound forms and class modules most of the
time.

Why do you use *unbound* forms when they are supposed to operate upon
data? Bound forms do these jobs quite well, and they're built in.

This is not (merely) a criticising statement, there are times I don't
like the way Access handles various events so I'd like to see your chain
of thought.

[Johnny M]

> When you open the form, use the DataMode argument to open in Add or Edit

mode, depending on whether you want to add a new record or edit an existing
one. If you're editing an existing record, pass the PK value of the record
in the OpenArgs argument and have your editing form filter the underlying
data source to find this record.

The forms are unbound, so the ADD/EDIT mode is irrelevant, right? Also, I
avoid openargs. I use classes stored in global variables to pass info between
forms.

I'm really looking for a way to mimic inheritance. So, for instance, if I have
a class Document, three derived classes, IDR, NPA, and Claim. I would like
a single Document form, that is changed appropriately based on what Document
I'm actually working with. In VBA, I just have the three class modules IDR,
NPA, and Claim (no abstract class Document, of course.) I just want to know
if anyone has any technique to do this with a form so I don't have to maintain
a bunch of forms that look nearly identical.

[Darryl Kerkeslager]

Most of my forms are set up like so:

A listBox at the bottom of the form contains a list of all records. Next to
the listBox are two buttons, Edit and New. The New button adds a new
record; the Edit button Finds the needed record and makes it the current
record.

The form is originally opened with all controls except these disabled; only
by selecting Edit or New do the textBoxes and comboBoxes for entereing data
become enabled. Save and Cancel buttons return control to the listBox and
disable the other controls after saving/cancelling.

When a form is loaded, or at some point prior, data from the BE table is
copied to an identical FE table, which is used as the recordsource for the
FE bound form. On Save, the new/edited record is copied to the BE table. I
gain what is to me the considerable benefit of using bound forms, without
the drawbacks of using linked tables.
Darryl Kerkeslager
"Johnny M" <jm*******@gmai l.com> wrote:

I have several databases where I have one form to add a new record and one form to edit an existing record. I use unbound forms and class modules most of the time.

What I would like to do is have one form that handles both adding a new record to the database and editing the same type of record. The form would be altered in the load event to change whatever needs to be changed to show the form
in an "Add" mode vs. and "Edit" mode (I guess???).

[Bas Cost Budde]

Johnny M wrote:

I have several databases where I have one form to add a new record and one form
to edit an existing record. I use unbound forms and class modules most of the
time.

What I would like to do is have one form that handles both adding a new record
to the database and editing the same type of record. The form would be altered
in the load event to change whatever needs to be changed to show the form
in an "Add" mode vs. and "Edit" mode (I guess???).

Does anyone have any ideas/experience on this? I'm sure in an truly OOP
environment this is childs play/standard operating procedure. Please let me
know what you think.

How would you like to handle tables with (vastly) different amounts of
fields? Controls can be created (and deleted) in design view only.

I get the impression I am interested in your project. Do you care for an
email discussion?

[John Winterbottom]

"Johnny M" <jm*******@gmai l.com> wrote in message
news:55******** *************** ***@posting.goo gle.com...

When you open the form, use the DataMode argument to open in Add or Edit
mode, depending on whether you want to add a new record or edit an
existing
one. If you're editing an existing record, pass the PK value of the
record
in the OpenArgs argument and have your editing form filter the underlying
data source to find this record.

The forms are unbound, so the ADD/EDIT mode is irrelevant, right? Also, I
avoid openargs. I use classes stored in global variables to pass info
between
forms.

I'm really looking for a way to mimic inheritance. So, for instance, if I
have
a class Document, three derived classes, IDR, NPA, and Claim. I would
like
a single Document form, that is changed appropriately based on what
Document
I'm actually working with. In VBA, I just have the three class modules
IDR,
NPA, and Claim (no abstract class Document, of course.) I just want to
know
if anyone has any technique to do this with a form so I don't have to
maintain
a bunch of forms that look nearly identical.

I would suggest changing to use bound forms - otherwise you're creating a
lot of extra work for yourself with input validation. Plus you lose the
advantage of many of the form's data-driven events. If you don't want to
maintain a connection to the underlying data source you can create your own
recordset using ADO, disconnect it from the underlying source and then bind
it to the form. When the user presses OK, you just walk through the
recordset and update or add the record in code as appropriate. I know this
technique works for SQL Server data - I think it also works for Jet in
Access XP but you'll need to check that one.

[rkc]

"Johnny M" <jm*******@gmai l.com> wrote in message
news:55******** *************** ***@posting.goo gle.com...

When you open the form, use the DataMode argument to open in Add or Edit
mode, depending on whether you want to add a new record or edit an existing one. If you're editing an existing record, pass the PK value of the record in the OpenArgs argument and have your editing form filter the underlying data source to find this record.
The forms are unbound, so the ADD/EDIT mode is irrelevant, right? Also, I
avoid openargs. I use classes stored in global variables to pass info

between forms.

I'm really looking for a way to mimic inheritance. So, for instance, if I have a class Document, three derived classes, IDR, NPA, and Claim. I would like a single Document form, that is changed appropriately based on what Document I'm actually working with. In VBA, I just have the three class modules IDR, NPA, and Claim (no abstract class Document, of course.) I just want to know if anyone has any technique to do this with a form so I don't have to maintain a bunch of forms that look nearly identical.

You mimic inheritance in VBA using containment and delegation. Two concepts
that you should be familiar with if you're interested in using OOP with
Access.

The only practical way of using a single form for multiple operations is to
create one that contains all the controls neccesary for each. Make all
common controls visible and show any additional ones when needed.

Instead of passing a document object to a form your document object would
contain an instance of the form. The appearance of the form and the showing
of additional controls is handled when the document object is instantiated.
Obviously your Document object would have complete knowledge of the form's
controls and would have to handle some of the events.

Personally I'd take another look at using multiple bound forms.

[Bob Quintal]

jm*******@gmail .com (Johnny M) wrote in
news:55******** *************** ***@posting.goo gle.com:

I have several databases where I have one form to add a new
record and one form to edit an existing record. I use unbound
forms and class modules most of the time.

What I would like to do is have one form that handles both
adding a new record to the database and editing the same type
of record. The form would be altered in the load event to
change whatever needs to be changed to show the form in an
"Add" mode vs. and "Edit" mode (I guess???).

Does anyone have any ideas/experience on this? I'm sure in an
truly OOP environment this is childs play/standard operating
procedure. Please let me know what you think.

Johnny

With a bound form, it's as easy as opening the form with
different arguments,
DoCmd.OpenForm stDocName,,,,ac FormAdd
DoCmd.OpenForm stDocName,,,,ac FormEdit

--
Bob Quintal

PA is y I've altered my email address.

[Johnny M]

> I would suggest changing to use bound forms - otherwise you're creating a

lot of extra work for yourself with input validation.

Do you use table level validation rules? Where does you validation occur when
using bound forms?