Is it possible to cancel events tied to fields depending on what mode form is opened in?

[allyn44]

HI--what I am trying to do is 2 things:

1. Open a form in either data entry mode or edit mode depending on
what task the user is performing
2. Cancel events tied to fields on the form if I am in edit mode.

The reason I want to do this is becasue when entering a new record the
form is entered in data entry mode and I have lots of stuff happening
upon entering and leaving fields. In edit mode I do not want the
events to fire.

I would like to avoid making a second set of forms for editing if I
can avoid it

thanks
bob

[Steve Jorgensen]

On Sat, 21 May 2005 14:47:16 -0700, al*****@cox.net wrote:

HI--what I am trying to do is 2 things:

1. Open a form in either data entry mode or edit mode depending on
what task the user is performing
2. Cancel events tied to fields on the form if I am in edit mode.

The reason I want to do this is becasue when entering a new record the
form is entered in data entry mode and I have lots of stuff happening
upon entering and leaving fields. In edit mode I do not want the
events to fire.

I would like to avoid making a second set of forms for editing if I
can avoid it

I'm not sure if there's a way of checking to see if the form is in data entry
mode, per se, but in the worst case, you can just pass a parameter to OpenArgs
that the code in the form can examine to determine how it should behave.

Also, if you just want to know if the current record is new/unsaved, you can
check the NewRecord property of the form.

[David W. Fenton]

al*****@cox.net wrote in
news:er********************************@4ax.com:

HI--what I am trying to do is 2 things:

1. Open a form in either data entry mode or edit mode depending on
what task the user is performing
2. Cancel events tied to fields on the form if I am in edit mode.

The reason I want to do this is becasue when entering a new record
the form is entered in data entry mode and I have lots of stuff
happening upon entering and leaving fields. In edit mode I do not
want the events to fire.

I would like to avoid making a second set of forms for editing if
I can avoid it

That's precisely why I tend to use a different form for adding
records than for editing, because you can end up with massive
convolution trying to handle two often contradictory sets of
requirements in one form.

The key is this;

Your New Record form need not be identical. All it needs to have is
the minimal set of fields required to create a valid record. Once
those are populated on the New Record form (which should be unbound,
so that it's easy to cancel the addition without needing to undo an
insert), insert the record in code using a recordset with the
argument dbAppendOnly (Set rsAdd = db.OpenRecordset(strSQL, ,
dbAppendOnly), then add the values from the unbound form to the
fields of the recordset, and record the new record's primary key
value (I'm assuming an AutoNumber PK). Use that PK value to open the
new record in your regular data editing form so the user can
complete any additional data entry.

Years ago I struggled with trying to do what you're attempting, as
well as trying to maintain identical appearing forms, one for add
and one for edit. I ran into just the kind of problem you're
encountering, plus the annoyance of having to delete a record (and
losing PK values in AutoNumber fields) when the Add was cancelled by
the user.

The unbound form with the subset of required fields only avoids all
those problems and allows you to optimize the two forms for the
completely separate purposes.

Of course, the hardest part may be deciding which fields really are
the required fields, i.e., the ones that you have to populate in
order to create a valid new record. But in a properly-designed data
schema, that should already be part of the design of the table. If
it's not, then your schema is incomplete.

The other advantage to this approach is that you can put any
duplicate checking code behind this form, instead of relying on mere
index collisions to catch dupes. The reason I use the adjective
"mere" is because indexes are dumb in terms of identifying dupes --
they only trigger when the data in a second record is entered
identically, whereas close records may want to be scrutinized by a
human being for possible duplicate status. Simple example: Is Bill
R. Smith a duplicate of the existing record William R. Smith? Can't
check for that with indexes, but you sure can with code, and having
it behind a dedicated New Record form makes it easy.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[allyn44]

Thanks David--MY RESPONSES IN CAPS BELOW

I would like to avoid making a second set of forms for editing if

I can avoid it

On Sat, 21 May 2005 22:13:03 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

That's precisely why I tend to use a different form for adding
records than for editing, because you can end up with massive
convolution trying to handle two often contradictory sets of
requirements in one form.

The key is this;

Your New Record form need not be identical. All it needs to have is
the minimal set of fields required to create a valid record. Once
those are populated on the New Record form (which should be unbound,
so that it's easy to cancel the addition without needing to undo an
insert), insert the record in code using a recordset with the
argument dbAppendOnly (Set rsAdd = db.OpenRecordset(strSQL, ,
dbAppendOnly), then add the values from the unbound form to the
fields of the recordset, and record the new record's primary key
value (I'm assuming an AutoNumber PK). Use that PK value to open the
new record in your regular data editing form so the user can
complete any additional data entry. I HAVE THIS SETUP IN ANOTHER PROJECT I AM WORKING ON--FOR THIS ONE
THOUGH, ALL FIELDS ARE NEcCESARY AS THE DATA CHaNGES FOR EACH RECORD
(WITH THE EXCEPTION OF THE ID FOR EACH SUBJECT ON SOME CONTINOUS
FORMS)Years ago I struggled with trying to do what you're attempting, as
well as trying to maintain identical appearing forms, one for add
and one for edit. I ran into just the kind of problem you're
encountering, plus the annoyance of having to delete a record (and
losing PK values in AutoNumber fields) when the Add was cancelled by
the user. DO NOT ALLOW THIS--HAVE AN ERROR REPORT FORM THAT LOGS THESE
SITUATIONS--THEN I TAKE CARE OF THESE MISTAKES

Of course, the hardest part may be deciding which fields really are
the required fields, i.e., the ones that you have to populate in
order to create a valid new record. But in a properly-designed data
schema, that should already be part of the design of the table. If
it's not, then your schema is incomplete. EASY ON SOME OF MY PROJECTS--NOT SO ON OTHERS :(
The other advantage to this approach is that you can put any
duplicate checking code behind this form, instead of relying on mere
index collisions to catch dupes.

I AGREE AND MANY ARE THE EVENTS THAT I MENTIONED THAT FIRE WHEN
CREATING A NEW RECORD--BUT SOME ARE NOT WANTED IN EDIT MODE--AND VISA
VERSA

IE--I HAVE AN AUDIT TRAIL MODULE THAT IS CONNECTE TO FORMS SO I CAN
KEEP PEOPLE OUT OF THE TABLES--BUT I ONLY NEED IT FOR EDITING RECORD.
WHEN PEOPLE CREATE NEW RECS I OPEN THE FORMS IN DATA ENTRY MODE SO
EXISTING RECS DON'T SHOW.
So your opinion is it would be best to keep the forms separate? for
this project there are only about 10 forms--so it is not a big
deal--but as I work on larger projects--I am afraid this may becomse
impractical.

thanks
bob

[David W. Fenton]

al*****@cox.net wrote in
news:ts********************************@4ax.com:

Thanks David--MY RESPONSES IN CAPS BELOW

I would like to avoid making a second set of forms for editing if

I can avoid it On Sat, 21 May 2005 22:13:03 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

That's precisely why I tend to use a different form for adding
records than for editing, because you can end up with massive
convolution trying to handle two often contradictory sets of
requirements in one form.

The key is this;

Your New Record form need not be identical. All it needs to have
is the minimal set of fields required to create a valid record.
Once those are populated on the New Record form (which should be
unbound, so that it's easy to cancel the addition without needing
to undo an insert), insert the record in code using a recordset
with the argument dbAppendOnly (Set rsAdd =
db.OpenRecordset(strSQL, , dbAppendOnly), then add the values from
the unbound form to the fields of the recordset, and record the
new record's primary key value (I'm assuming an AutoNumber PK).
Use that PK value to open the new record in your regular data
editing form so the user can complete any additional data entry.
I HAVE THIS SETUP IN ANOTHER PROJECT I AM WORKING ON--FOR THIS ONE
THOUGH, ALL FIELDS ARE NEcCESARY AS THE DATA CHaNGES FOR EACH
RECORD (WITH THE EXCEPTION OF THE ID FOR EACH SUBJECT ON SOME
CONTINOUS FORMS)

I have never encountered a table that required a form of any
complexity that had so few fields that all of them are required --
that's the type of thing I'd expect for small tables with a handful
of fields (3, 4, maybe even 5), but never for any table with any
moderate number of attributes.
Years ago I struggled with trying to do what you're attempting, as
well as trying to maintain identical appearing forms, one for add
and one for edit. I ran into just the kind of problem you're
encountering, plus the annoyance of having to delete a record (and
losing PK values in AutoNumber fields) when the Add was cancelled
by the user.

DO NOT ALLOW THIS--HAVE AN ERROR REPORT FORM THAT LOGS THESE
SITUATIONS--THEN I TAKE CARE OF THESE MISTAKES

Do not allow what? Deletion of records? Cancelling of an Add
operation? I take it, then, that you are trapping for the ESCAPE key
when in DataEntry mode?

Of course, the hardest part may be deciding which fields really
are the required fields, i.e., the ones that you have to populate
in order to create a valid new record. But in a properly-designed
data schema, that should already be part of the design of the
table. If it's not, then your schema is incomplete.

EASY ON SOME OF MY PROJECTS--NOT SO ON OTHERS :(

I suspect you have an overly pessimistic definition of "required
fields." All that should be necessary to create a new record are the
fields required to be able to distinguish one record from another.
The other details can be left until later.

The other advantage to this approach is that you can put any
duplicate checking code behind this form, instead of relying on
mere index collisions to catch dupes.

I AGREE AND MANY ARE THE EVENTS THAT I MENTIONED THAT FIRE WHEN
CREATING A NEW RECORD--BUT SOME ARE NOT WANTED IN EDIT MODE--AND
VISA VERSA

IE--I HAVE AN AUDIT TRAIL MODULE THAT IS CONNECTE TO FORMS SO I
CAN KEEP PEOPLE OUT OF THE TABLES--BUT I ONLY NEED IT FOR EDITING
RECORD. WHEN PEOPLE CREATE NEW RECS I OPEN THE FORMS IN DATA ENTRY
MODE SO EXISTING RECS DON'T SHOW.

Well, having two different forms for this seems to me to be a very
easy way to accomplish this.

On the other hand I'm having some difficulty understanding why
checking for the .NewRecord or .DataEntry properties for conditional
execution of your code. If it's designed properly, it should be
easy:

If Not (Me.NewRecord Or Me.DataEntry) Then Call AuditCode(Me)

For clarity's sake, I just passed a form reference to the outside
audit subroutine, since you'd probably be passing a bunch of
parameters to write your audit record. If I were doing this, I'd
probably have a subroutine in each form that made the call to the
outside subrouting and included all the parameters, and then call
that without an arguments from all the subs within the form. This
would make the code a lot cleaner and simpler; if you need the value
of a control that has the focus, you could pass a control reference
to your local subroutine.

Of course, if you've written a subroutine local to the form to call
the audit code, then you could have the conditional test there,
instead of each time you call the local audit function.

So, I think that if you structure your code well, it shouldn't be
that hard to have conditional calling of your audit routines.
So your opinion is it would be best to keep the forms separate?
for this project there are only about 10 forms--so it is not a big
deal--but as I work on larger projects--I am afraid this may
becomse impractical.

Well, as I said, if there is a natural subset of required fields,
then it makes sense to use a separate, lightweight form for the Add
process. If you can't do that, then you need to do conditional
execution of code, and that is made easiest by structuring your code
in a fashion that minimizes code duplication.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[allyn44]

ALL FIELDS ARE NEcCESARY AS THE DATA CHaNGES FOR EACH
RECORD (WITH THE EXCEPTION OF THE ID FOR EACH SUBJECT ON SOME
CONTINOUS FORMS)
I have never encountered a table that required a form of any
complexity that had so few fields that all of them are required --
that's the type of thing I'd expect for small tables with a handful
of fields (3, 4, maybe even 5), but never for any table with any
moderate number of attributes. I am confused here--probably not explaining myself well enough.
Maybe it is what I am defininig as "required" fields.

My new record in any particular table is created as I enter all data
for that particular record--maybe I should mention this is clinical
data entered on standardized forms at one time point. Each table has
an autonumber and also has a subjectID. The subject ID is what joins
each separate table together and is pulled from table to table (form
to form to the user)through a series of forms the user enters and
exits in sequence (demographic data, Medical history, Blood lab
results, etc.)Other than the subject ID, the user is entering a series
of paper forms into access forms at one time point.
Do not allow what? Deletion of records? Cancelling of an Add
operation? I take it, then, that you are trapping for the ESCAPE key
when in DataEntry mode? Thank you for reminding me to do that.
I suspect you have an overly pessimistic definition of "required
fields." All that should be necessary to create a new record are the
fields required to be able to distinguish one record from another.
The other details can be left until later. Again confused as to the definition of "later." Later to me meaning a
different data entry session.

If Not (Me.NewRecord Or Me.DataEntry) Then Call AuditCode(Me) THIS IS EXACTLY WHAT I NEEDED FOR WHAT I WANT TO DO!!! i CAN ALSO USE
THIS TO CANCEL EVENTS DEPENDING UPON THE MODE OF THE FORM. Thank You!
Well, as I said, if there is a natural subset of required fields,
then it makes sense to use a separate, lightweight form for the Add
process. If you can't do that, then you need to do conditional
execution of code, and that is made easiest by structuring your code
in a fashion that minimizes code duplication.

Thank you again David for taking the time to give your input. I am
not an expert--just the one who volunteered to do the work when
someone was needed--and have been on a steady learning curve since.
Haiving this group and the helpful peole in it has been a great
experience.

Bob

[David W. Fenton]

al*****@cox.net wrote in
news:re********************************@4ax.com:

ALL FIELDS ARE NEcCESARY AS THE DATA CHaNGES FOR EACH
RECORD (WITH THE EXCEPTION OF THE ID FOR EACH SUBJECT ON SOME
CONTINOUS FORMS)
I have never encountered a table that required a form of any
complexity that had so few fields that all of them are required --
that's the type of thing I'd expect for small tables with a
handful of fields (3, 4, maybe even 5), but never for any table
with any moderate number of attributes.
I am confused here--probably not explaining myself well enough.
Maybe it is what I am defininig as "required" fields.

Yes, I think so. Required to create a record in the database is not
the same as "required to be filled out by the business rules of the
application."
My new record in any particular table is created as I enter all
data for that particular record--maybe I should mention this is
clinical data entered on standardized forms at one time point.
Each table has an autonumber and also has a subjectID. The subject
ID is what joins each separate table together and is pulled from
table to table (form to form to the user)through a series of forms
the user enters and exits in sequence (demographic data, Medical
history, Blood lab results, etc.)Other than the subject ID, the
user is entering a series of paper forms into access forms at one
time point.

Sounds to me like a perfect case for a wizard type interface, with
<<Previous and Next>> buttons to step the use through a required set
of tasks.

Do not allow what? Deletion of records? Cancelling of an Add
operation? I take it, then, that you are trapping for the ESCAPE
key when in DataEntry mode?

Thank you for reminding me to do that.

Again, I think you could avoid this kind of issue entirely and *not*
need to trap for it if you separated the record creation and record
editing processes into two different forms.

I suspect you have an overly pessimistic definition of "required
fields." All that should be necessary to create a new record are
the fields required to be able to distinguish one record from
another. The other details can be left until later.

Again confused as to the definition of "later." Later to me
meaning a different data entry session.

No, all I was saying was create the stump record, then immediately
open the form for editing the whole record.

If Not (Me.NewRecord Or Me.DataEntry) Then Call AuditCode(Me)

THIS IS EXACTLY WHAT I NEEDED FOR WHAT I WANT TO DO!!! i CAN ALSO
USE THIS TO CANCEL EVENTS DEPENDING UPON THE MODE OF THE FORM.
Thank You!

But that's basically just a variation on the very first suggestions
you received in response to your original post.

Well, as I said, if there is a natural subset of required fields,
then it makes sense to use a separate, lightweight form for the
Add process. If you can't do that, then you need to do conditional
execution of code, and that is made easiest by structuring your
code in a fashion that minimizes code duplication.

Thank you again David for taking the time to give your input. I am
not an expert--just the one who volunteered to do the work when
someone was needed--and have been on a steady learning curve
since. Haiving this group and the helpful peole in it has been a
great experience.

Well, I'm glad it helped! I don't think my actual answers were
on-target for the questions you asked, but, as it turns out, what I
said helped you think things through in a way that has helped
resolve your problems, so my answers worked after all!

That kind of thing happens to me all the time -- an answer that
misses the point actually takes care of the original question after
all.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc