Why/when does close save?

  • Thread starter Thread starter OceanView
  • Start date Start date
O

OceanView

You're in a record, change a field, then close the form. The record
gets saved automatically. Is there a way to prevent this? And how
do I catch it? A form_close event doesn't seem to work because
me.dirty =false. Would you have to do a confirm on *every* before-
update event?
 
The Form has a BeforeUpdate event in which you can set Cancel to cancel the
update. Close will save the Record if anything has been modified, e.g., the
Form is Dirty.

Larry Linson
Microsoft Access MVP
 
The Form has a BeforeUpdate event in which you can set Cancel to
cancel the update. Close will save the Record if anything has
been modified, e.g., the Form is Dirty.

Larry Linson
Microsoft Access MVP
Click to expand...

Yes, I know that. But I Want to know if that's happening because the
form is closing. I suppose I can disable the close box and force
them to use close button control, but that seems clumsy. Is seems
like the events happen in the wrong order.
 
OceanView said:
Yes, I know that. But I Want to know if that's happening because the
form is closing. I suppose I can disable the close box and force
them to use close button control, but that seems clumsy. Is seems
like the events happen in the wrong order.
Click to expand...

I use one of these:
+++++++++++++++++++++++++++++
Private Sub Form_BeforeUpdate(Cancel As Integer)
Dim Response
If Me.Dirty = True Then
Response = msgbox("Do you want to save the changes?", vbYesNo)
If Response = vbYes Then
'do nothing
Else
Me.Undo
End If
End If
End Sub
+++++++++++++++++++++++++++++

HTH

- Peter
 
The Form has a BeforeUpdate event in which you can set Cancel to
cancel the update. Close will save the Record if anything has
been modified, e.g., the Form is Dirty.

Larry Linson
Microsoft Access MVP
Click to expand...
[...]


Yes, I know that. But I Want to know if that's happening because the
form is closing. I suppose I can disable the close box and force
them to use close button control, but that seems clumsy. Is seems
like the events happen in the wrong order.
Click to expand...

Closing the form will cause the "BeforeUpdate" event to be fired as will moving
to another record or moving between a main form and subform (and you likely knew
that, too). What you perceive as clumsy is actually a commonly used approach for
controlling user activities at both the form level and the application level.
The order in which the events occur is by design and works best for those who
need to make use of them. For more information on the order of events, see:

http://msdn.microsoft.com/library/d...ce97/html/managingeventsinyourapplication.asp

.... and Access Help.
 
Peter Smith said:
Private Sub Form_BeforeUpdate(Cancel As Integer)
Dim Response
If Me.Dirty = True Then
Response = msgbox("Do you want to save the changes?", vbYesNo)
If Response = vbYes Then
'do nothing
Else
Me.Undo
End If
End If
End Sub
Click to expand...

Pardon me, but that "If Me.Dirty = True" test doesn't seem to me to make
sense. If the form's BeforeUpdate event has fired, the form *must* be
dirty.
 
The Form has a BeforeUpdate event in which you can set Cancel
to cancel the update. Close will save the Record if anything
has been modified, e.g., the Form is Dirty.

Larry Linson
Microsoft Access MVP
Click to expand...
[...]


Yes, I know that. But I Want to know if that's happening
because the form is closing. I suppose I can disable the close
box and force them to use close button control, but that seems
clumsy. Is seems like the events happen in the wrong order.
Click to expand...

Closing the form will cause the "BeforeUpdate" event to be fired
as will moving to another record or moving between a main form
and subform (and you likely knew that, too). What you perceive
as clumsy is actually a commonly used approach for controlling
user activities at both the form level and the application
level. The order in which the events occur is by design and
works best for those who need to make use of them. For more
information on the order of events, see:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
office97/html/managingeventsinyourapplication.asp

... and Access Help.
Click to expand...

I guess what I meant by clumsy, is that there doesn't seem any to
trace the event chain, so that, in before_update I can tell whether
the record is being updated because they are changing records, or
because the form is closing.

But thanks for the help, folks!
 
I guess what I meant by clumsy, is that there doesn't seem any to
trace the event chain, so that, in before_update I can tell whether
the record is being updated because they are changing records, or
because the form is closing.
Click to expand...

Actually, you referred to disabling the close box as "clumsy" and my reply was
to that reference.

:-)
 
OceanView said:
news:[email protected]:
Click to expand...
I guess what I meant by clumsy, is that there doesn't seem any to
trace the event chain, so that, in before_update I can tell whether
the record is being updated because they are changing records, or
because the form is closing.
Click to expand...

Well, if the record HAS NOT been edited, then the before update event WILL
NOT fire.

If the record has been modified, then the before update event will fire.

The above occurs if you close the form with the X. or any other means.

So, if are you trying to trap the fact that the record has been edited, that
code can simply be put in the before update event. The fact that you used
the "x" to close the form DOES NOT change this fact.

If the form has not been edited...then the before update code does not run.

So, if the form is closing, and you modified the data...then before update
runs. If the form is closing, and you did not modify the data...then before
update does NOT run.

You can certainly have some code in the forms close event. However, why does
it make a difference if the record is being updated due to record movement,
or the form being closed? (in both cases...you want to update the
record...right?).

You can always set a global flag in the forms on-current event. Then, in the
before update event, you can go:

dataMod = true


Then, in the close event of the form, you can go:

if dataMod = True then

msgbox "form closed, and data was saved/modified"

else

msgbox "form closed...data was not changed"

end if

Still at a loss as to why you need the above...but it will work...
 
Well, if the record HAS NOT been edited, then the before update
event WILL NOT fire.

If the record has been modified, then the before update event
will fire.

The above occurs if you close the form with the X. or any other
means.

So, if are you trying to trap the fact that the record has been
edited, that code can simply be put in the before update event.
The fact that you used the "x" to close the form DOES NOT change
this fact.

If the form has not been edited...then the before update code
does not run.

So, if the form is closing, and you modified the data...then
before update runs. If the form is closing, and you did not
modify the data...then before update does NOT run.

You can certainly have some code in the forms close event.
However, why does it make a difference if the record is being
updated due to record movement, or the form being closed? (in
both cases...you want to update the record...right?).

You can always set a global flag in the forms on-current event.
Then, in the before update event, you can go:

dataMod = true


Then, in the close event of the form, you can go:

if dataMod = True then

msgbox "form closed, and data was saved/modified"

else

msgbox "form closed...data was not changed"

end if

Still at a loss as to why you need the above...but it will
work...


--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
(e-mail address removed)
http://www.attcanada.net/~kallal.msn
Click to expand...

Yes, I thnk that's the answer. I was using the current event to
handle record movement and updates, but that won't handle all
circumstances unconditionally, as you pointed out.
 
Well, if the record HAS NOT been edited, then the before update
event WILL NOT fire.

If the record has been modified, then the before update event
will fire.

The above occurs if you close the form with the X. or any other
means.

So, if are you trying to trap the fact that the record has been
edited, that code can simply be put in the before update event.
The fact that you used the "x" to close the form DOES NOT change
this fact.

If the form has not been edited...then the before update code
does not run.

So, if the form is closing, and you modified the data...then
before update runs. If the form is closing, and you did not
modify the data...then before update does NOT run.

You can certainly have some code in the forms close event.
However, why does it make a difference if the record is being
updated due to record movement, or the form being closed? (in
both cases...you want to update the record...right?).

You can always set a global flag in the forms on-current event.
Then, in the before update event, you can go:

dataMod = true


Then, in the close event of the form, you can go:

if dataMod = True then

msgbox "form closed, and data was saved/modified"

else

msgbox "form closed...data was not changed"

end if

Still at a loss as to why you need the above...but it will
work...


--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
(e-mail address removed)
http://www.attcanada.net/~kallal.msn
Click to expand...

Just another reply to explain. My customer was not happy that, if
they started a new record, then just closed the form, that the
record would be saved. They wanted only explicit saves, through
the use of a Save button. No automatic saves.
 
Just another reply to explain. My customer was not happy that, if
they started a new record, then just closed the form, that the
record would be saved. They wanted only explicit saves, through
the use of a Save button. No automatic saves.
Click to expand...

Declare a form-level boolean variable. Check that variable's value in the form's
"BeforeUpdate" event procedure and if it's False, undo the record, otherwise go
ahead and save. In the "Save" button's code, set the variable's value to True
just prior to the code that invokes the save and set it back to False
afterwards:

'***Declare Form-level variable
Dim bOkToSave As Boolean
'***

'***Save Button Code Example
'Allow save
bOkToSave = True
'Save, if form is dirty
If Me.Dirty Then
Me.Dirty = False
End If
'Reset variable
bOkToSave = False
'***

'***Code in form's "BeforeUpdate" event procedure example
If bOkToSave = False
Me.Undo
End If
'***
 
Declare a form-level boolean variable. Check that variable's
value in the form's "BeforeUpdate" event procedure and if it's
False, undo the record, otherwise go ahead and save. In the
"Save" button's code, set the variable's value to True just
prior to the code that invokes the save and set it back to False
afterwards:

'***Declare Form-level variable
Dim bOkToSave As Boolean
'***

'***Save Button Code Example
'Allow save
bOkToSave = True
'Save, if form is dirty
If Me.Dirty Then
Me.Dirty = False
End If
'Reset variable
bOkToSave = False
'***

'***Code in form's "BeforeUpdate" event procedure example
If bOkToSave = False
Me.Undo
End If
'***
Click to expand...

I actually did exactly that in one form. Though what'd still like
to do is trap the close event before it saves, ask the user if they
want to save changes. This isn't at all unusual. Open Word, type
something, press the close button, get a dialog. That's all I'm
really trying to do.
 
I actually did exactly that in one form. Though what'd still like
to do is trap the close event before it saves, ask the user if they
want to save changes. This isn't at all unusual. Open Word, type
something, press the close button, get a dialog. That's all I'm
really trying to do.
Click to expand...

You don't get to the Close event before the form saves - only using the
"BeforeUpdate" event will allow you to cancel a save when the user has opted to
close the form, and this, of course, puts you back in the position of getting
prompted every time you try to move to another record. Both the Close and Unload
events don't fire until after the record has been committed. So implement
"exactly that", add a prompt to the code behind the "Save" button and change the
Caption of your "Save" button to "Close".

:-)
 
Back
Top