Hi folks, thought I'd throw one more post on the heap of complicated
form/subform event woes here at CDMA.

My setup is this: I have an unbound form which contains a bound
continuous subform. Everything's staging (until a user clicks save, at
which point bound and unbound data are fired off toward a persisted
back end), so dumping it when closing the form is automatic.

The subform does some validating in the Form_BeforeUpdate event, and
prevents the user from leaving the record if there is invalid data.
Even though it's a temp table, it's useful to do it while the user is
on a given record because the user's already there.

Problem is, when the main form gets closed, or its unbound record gets
cancelled, or whatever, there is no longer any need to validate that
data. And Access, alas, fires the BeforeUpdate event on the subform
before it "knows" that the main form is closing, i.e. it goes
something like this:
user chooses to dump --> subf BeforeUpdate fires, validates --> mainf
Close events occur

So in a situation where the user has entered invalid data and just
decides to kill the record--not that uncommon, after all--at least one
message pops up saying there's invalid data, and then even if I choose
to continue with the close, Access throws its own message warning the
user that the data in the record can't be saved--meaning the subform's
unupdated record--and asking if it's still ok to close.

I understand why the subform needs to store data before closing the
main form, and therefore why the events go in the order they do, but
there does not seem to be any exposed event even telling the subform
that a close/cancel state is coming from above. Or am I missing
something?

The short version: Can I somehow know the main form is closing while
still in a dirty subform, thus allowing me to choose to validate or
not?

Crossing my fingers that someone out there has worked through this
before. Thanks in advance for any insight.

downwitch wrote:

What you're missing is that it doesn't matter if the main
form is closing or not. As soon as the focus moves out of
the subform, whether it's back to the main form or to
another subform, the dirty subform must try to save its
data. That is necessary to preserve data integrity.

I think you will need to use a module variable to keep track
of what's going on in the subform. Set the variable to
False in the subform's Current event and set it to True in
the save button's Click event, before doing whatever you do
to save the data. Then the form's BeforeUpdate event can
test the variable, if it's False undo the record, else
proceed.

--
Marsh

Thanks for the reply. I understand that the conflict isn't occurring
specifically "because of" a close event on the main form. In fact,
*no* event taking place in the main form is known to the subform
before it tries to save its record. My validation is not built into
the subform's underlying table, so the data "can save" to the Access
table first, regardless of "validity" or of what is to come next, but
logically speaking, if I am abandoning the process in any way--
cancelling entry, closing the form without saving, etc.--no validation
should occur. If the validation doesn't matter to the table, the data
can save for an instant before the form closed and blew away the temp
record anyway. (Not sure that was clear before. Is it now? Heh.)

Current won't work because a) the record isn't dirty at that point,
and more importantly b) the user's intention--to save or to cancel--is
still unknown at that point. A module variable won't work either,
because it can't get "reset" in time to stop the validation. If a user
clicks a cancel button, e.g., the BeforeUpdate event *still fires*
before the button's event does. Can't win.

I am increasingly leaning toward moving away from the set of subform
events that fire first. Then the problem becomes, how do I leave those
events alone, but still simulate a before-update and keep the subform
from moving off its current record, in cases where I am not
cancelling. It's a pretty maddening little seesaw.

On Jul 16, 11:38*pm, Marshall Barton <marshbar... (AT) wowway (DOT) com> wrote:

downwitch wrote:
No it wasn't clear before and, no, it is not clear now.
Nor is it clear why that matters to this discussion.

That's why I said to reset the variable in the Current
event. If the BeforeUpdate event is triggered while the
variable is False, then your save button was not used and
you can undo the record and exit. If the save button was
used, the variable will be True so the validation can
proceed and if it passes, the record can be saved (however
you do that).

For any of this to make sense, the save and cancel buttons
must be on the subform.

The subform would have to be unbound for that to work, but
then it could not be continuous.

Marsh

Well fair enough. I shall try to spell it out as simply as I can,
because I can assure you that it is more than clear enough to me.

The bound subform must be bound to be continuous, as you point out.
Multiple records, but they are temp records, so "saving" them is
meaningless, until the master record gets saved. It's a grid of detail
data hanging off a master record, the end. So while it might make
technical sense to throw variables and save/cancel buttons into the
subform, it makes zero sense from a logical/business perspective:
every saved record in the subform is meaningless if the user cancels
the whole process. Current is a meaningless subform event in this
case: only dirt matters.

It's a data-entry setup, so you want to catch bad entries at the
moment of entry. Not to mention that continuous/datasheet scenarios
are always a bit misleading, as they only ever point to one record
anyway, and that one record with the bad data is the one that matters.
But all validation of an entered field (or multiple fields, as there
are rules that combine fields) is *meaningless*, once again, if the
user cancels the master record.

So yes, there are all sorts of ways I could "force" the user to
validate each subform record with a click. This would be dumb,
however, and in a classic data-entry setup, every keystroke (let alone
a mouse click, ugh) counts.

I want to validate the subform following the user's field-by-field or
record-by-record entry, *unless* the user wants to cancel the whole
shebang, in which case I want to validate nothing. But I can't get out
to cancel the main without validating the sub. If that doesn't make
sense, sorry, I can't put it any more plainly.

On Jul 18, 12:39*pm, Marshall Barton <marshbar... (AT) wowway (DOT) com> wrote:

Sheesh, I missed where you said the subform was bound to a
temp table. Sorry for wasting your time.

The only way I can see you avoiding the record validation in
the subform is if all edits/additions are done in unbound
controls, positioned to look like the current record. But
then it gets tricky finding a time/place to validate, save
and move the data to a real subform record. Maybe the
subform's Current event and the main form's save button??
Not sure it would be worth all that trouble though.
--
Marsh


downwitch wrote:

It's all good--I appreciate whatever help I can get on this.

One more thing to think about: the validation is not of the is-this-
data-ok-to-save variety, but rather of the no-that-doesn't-match-the-
rules variety. There is nothing on the temp table itself that would
stop the saving of the invalid data, if the UI rules didn't interfere.
So letting the controls be bound doesn't cause the problem--it's the
"decision" to validate or not.

On Jul 19, 12:42*am, Marshall Barton <marshbar... (AT) wowway (DOT) com> wrote:

So, with a better understanding of what you are trying to
do, we're back to your original question of how to not
validate when the focus moves out of the subform. Clearly,
the validation code can not be in the subform's Before (or
After) Update event because that will be triggered
automatically.

You could try doing it in the save button for all the saved,
but not validated, records in the temp table. The subform's
AfterUpdate event may need to maintain a collection of the
key for each temp table record that was saved during the
session so the save button could retrieve and validate those
records without wasting time on records that were already in
the real table and not changed.

If a subform record fails the validation checks, you could
make that record the subform's current record, set the focus
back to the subform and exit the save procedure. so the user
could try to fix the record.

At least this way, closing the main form will leave the temp
table to just die on the vine.
--
Marsh


downwitch wrote:

Yes, I thought about this direction as a good possibility. It's a
little more cumbersome from the coding and logic standpoint--why loop
through post facto when you could just watch in realtime--but I agree,
none of the more logical approaches seem to work when it comes time to
cancel.

I think the subform current event only fires on a record change (and
load of course, when everything's valid), so that is also a
possibility, because I don't think a subform/main form focus shift
moves the cursor. But again, waiting to get to record n+1 to check
record n is a little counterintuitive, too.

Validate automatically, but do an end-run around the Access event
definition of automatic. Sigh.


On Jul 19, 1:13*pm, Marshall Barton <marshbar... (AT) wowway (DOT) com> wrote:

I suggested using the subform's AfterUpdate event to log a
record into the records to be validated Collection, because
the Current event is too late to get to the changed record.

If you want to validate a record immediately instead of
waiting for the save button to do all the records, then the
Current event seems like the only place you can do it and
know that the subform still (or just got) the focus. This
would minimize the number of entries in the collection, but
make it messier because you would have to move back to the
record to be validated and, If it passes, renavigate to the
record the user just moved to.

Either way it's unpleasant, but doable.
--
Marsh


downwitch wrote: