Cancel changes to form and subform

[Gezza Collins]

Hi,

I have a bound form with a subform containing a datasheet. I want to
implement a cancel or comit buttons on the form, is there any sure fire way
of doing this on a bound form.

I've been down the route of using undo on the beforeupdate events of both
forms but you've always got the problem of multiple changes on the main form
and multiple changes on the sub form saving records automatically and
therefore not undoing all changes.

I'm leaning more towards creating unbound forms and writing the records on
the commit using recordsets but for piece of mind I'd like to know if there
is any way this can be done on a bound form and subform.

Example code:

Module Level:
--------------
Public gblCancel as Boolean

On Main Form:
---------------
Private Sub Form_Load()

gblCancel = False

End Sub

Private Sub cmdCancel_Click()

gblCancel = True
DoCmd.Close acForm, "tblInitMaster"

End Sub

Private Sub Form_BeforeUpdate(Cancel As Integer)

If gblCancel = True Then Me.Undo

End Sub


On Subform
-------------
Private Sub Form_BeforeUpdate(Cancel As Integer)

If gblCancel = True Then Me.Undo

End Sub

 

[John Webb via AccessMonster.com]

Yes there is a different method, one that I use all the time.

Private Sub ResetForm()
On Error Resume Next

Dim fld As Object

For Each fld In Me.Recordset.Fields
Me.Controls(fld.Name) = Me.Controls(fld.Name).OldValue
Next

End Sub

You use of a global variable to track whether the user has hit the Save or
Discard button is the right way to go about it; you would need to setup a
call to this function on the discard button.

However, you also need to trap for the page up and page down event; and
that bleeding mousewheel scroll is a pain; for that you will want to visit
the following link:

http://www.lebans.com/mousewheelonoff.htm

I know this is a long shot from a full answer to your question, but it
seems that you have more or less the right idea; so you should be able to
take this and run with it.

Any probs, post back.

Cheers

John webb

 

[Van T. Dinh]

I think Gezza is talking about the Form/Subform's "AutoSave" feature (which
is a necessary pain as the Form / Subform combiniation is designed to
preserve the Referential Integrity of the "One-to-Many" - related data.

The AutoSave will automatically save (what else?) the Record in the Main
Form as soon as the user tries to move the Focus to the Subform. It also
automatically save the Record in the Subform as soon as the user tries to
move the Focus from the Subform back to the Main Form.

Your code only works in a simple Form, not a Form/Subform combination.

 

[Van T. Dinh]

* Usual work-around: use temp Tables to temporarily store data for both the
Parent Record and the Child Records . When the user "commits", write these
to permanent Tables.

* A simple way is to hide the Subform and force the user to check and to
commit to the Parent Record before making the Subform visible.

* Another possibility (which I haven't tried): Create Recordsets "out of
thin air" (i.e. not sourced from your Tables) to hold the data temporarily
until user commits"at which time you can use the data from the "out of thin
air" Recordsets to write to the permanent Tables. This will involve a fair
bit of code.

 

[Celal]

I am not sure if I could get Gezza's problem right but if it's about
the default saving behaviour of Access (autosaving forms and subs as
they lose focus - not only closing them), I have a similar question;
and if this is the case, I'd like to share my codes.

I understand Gezza wants a cancel and a comit button, cancel to
obviously cancel the event and comit to save/close/update whatever. If
this is the case, working with my problem, I found a way to NOT save
the changes on the main form even if the focus moves to the subform
and you can undo it without deleting the record or duplicating it in a
temporary table. But I could not find the solution for the subform as
the buttons are on the main form and when clicked, subform already
loses focus. I feel I need to use NoSave somehow but do not have much
info on it.

I agree with Van T. Dinh that the default autosave feature of Access
is correct (what else - makes the user click another button each time
and makes the coders life hell) but sometimes, we must go with what
the users want.

So Gezza, if your question is related to this and you think it could
be helpful, please inform and i'll post the code i have. Do not want
to waste space if i misunderstood the question. And if anybody can
help me with my problem, I'd appreciate (Haven't posted it here yet
but will do).

Celal