Dirty Event for Form is not "firing".

[Susan Bricker]

I am currently using the OnDirty event of a Form to detect whether any
fields have been modified. I set a boolean variable. Then, if the
Close button is clicked before the Save button, I can put up a message
on the screen that will tell the user that "Data has been changed, do
you wish to Save the record before Closing this window?"

I think I've just discovered this only works if the record that is being
displayed/modified it not a NewRecord.

How should I deal with the situation when the User is working on a
NewRecord and (supposedly) has filled in all the required fields and
then hits the Close Button before hitting the Save button?

Regards,
SueB

*** Sent via Developersdex http://www.developersdex.com ***

[Allen Browne]

In some versions of Access, the form's Dirty event will not fire if the
record is dirtied programmaticall y.

For example, if you assign a value to a bound control in the Current event
of the form, its Dirty event will not fire.

Is there are need to use this event to manage your own variable? The form
already has a dirty property, so you could code:
If Me.Dirty Then ...

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Susan Bricker" <sl*****@verizo n.net> wrote in message
news:YW******** *********@news. uswest.net...

I am currently using the OnDirty event of a Form to detect whether any
fields have been modified. I set a boolean variable. Then, if the
Close button is clicked before the Save button, I can put up a message
on the screen that will tell the user that "Data has been changed, do
you wish to Save the record before Closing this window?"

I think I've just discovered this only works if the record that is being
displayed/modified it not a NewRecord.

How should I deal with the situation when the User is working on a
NewRecord and (supposedly) has filled in all the required fields and
then hits the Close Button before hitting the Save button?

[Salad]

Allen Browne wrote:

In some versions of Access, the form's Dirty event will not fire if the
record is dirtied programmaticall y.

For example, if you assign a value to a bound control in the Current event
of the form, its Dirty event will not fire.

Is there are need to use this event to manage your own variable? The form
already has a dirty property, so you could code:
If Me.Dirty Then ...

Hi Allen. I think this situation can be examined easily. I created a
table called Table1. It contained 3 fields
ID; Autonumber
Test1; Text
Test2; Text.

I created a form using the wizard for Table1.

I then dropped the code below into it. You can't stop new record loss
as near as I can determine. Try it out with only new records first.
Go to a new record
In field Test1 (less than 4 chars to fire BeforeUpdate Cancel)
Tab to field Test2.
Now click on the X button.

There is no way I can see that you can stop a New Record that may
contain some data from being lost.

Option Compare Database
Option Explicit
Dim intMouseCnt As Integer
Dim blnX As Boolean
Private Sub Form_AfterUpdat e()
MsgBox "After Update"
End Sub
Private Sub Form_BeforeUpda te(Cancel As Integer)
If Len(Me.Test1) < 4 Then
MsgBox "Less 4"
Cancel = True
End If
End Sub
Private Sub Form_Close()
MsgBox "Close"
End Sub
Private Sub Form_Deactivate ()
MsgBox "Deactivate Dirty " & Me.Dirty
MsgBox "Deactivate New Record " & Me.NewRecord
MsgBox "Deactivate test1 = " & Me.Test1

End Sub
Private Sub Form_Error(Data Err As Integer, Response As Integer)
MsgBox "Error Dataerr " & DataErr
MsgBox "Error Dirty " & Me.Dirty
MsgBox "Error New Record " & Me.NewRecord
MsgBox "Error test1 = " & Me.Test1

'No can do
'If DataErr = 2169 Then Me.Dirty = False

Response = acDataErrContin ue
End Sub
Private Sub Form_Unload(Can cel As Integer)
If Not blnX Then
MsgBox "Unload Dirty " & Me.Dirty
MsgBox "Unload New Record " & Me.NewRecord
MsgBox "Unload test1 = " & Me.Test1

'Cancel does absolutely nothing because the code
'doesn't even execute before the new record
'with data is wiped out.
Cancel = True
blnX = True
End If
End Sub

[Allen Browne]

No idea how that relates to the OP's q.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Salad" <oi*@vinegar.co m> wrote in message
news:6n******** ********@newsre ad1.news.pas.ea rthlink.net...

Allen Browne wrote:

In some versions of Access, the form's Dirty event will not fire if the
record is dirtied programmaticall y.

For example, if you assign a value to a bound control in the Current
event of the form, its Dirty event will not fire.

Is there are need to use this event to manage your own variable? The form
already has a dirty property, so you could code:
If Me.Dirty Then ...

Hi Allen. I think this situation can be examined easily. I created a
table called Table1. It contained 3 fields
ID; Autonumber
Test1; Text
Test2; Text.

I created a form using the wizard for Table1.

I then dropped the code below into it. You can't stop new record loss as
near as I can determine. Try it out with only new records first.
Go to a new record
In field Test1 (less than 4 chars to fire BeforeUpdate Cancel)
Tab to field Test2.
Now click on the X button.

There is no way I can see that you can stop a New Record that may contain
some data from being lost.

Option Compare Database
Option Explicit
Dim intMouseCnt As Integer
Dim blnX As Boolean
Private Sub Form_AfterUpdat e()
MsgBox "After Update"
End Sub
Private Sub Form_BeforeUpda te(Cancel As Integer)
If Len(Me.Test1) < 4 Then
MsgBox "Less 4"
Cancel = True
End If
End Sub
Private Sub Form_Close()
MsgBox "Close"
End Sub
Private Sub Form_Deactivate ()
MsgBox "Deactivate Dirty " & Me.Dirty
MsgBox "Deactivate New Record " & Me.NewRecord
MsgBox "Deactivate test1 = " & Me.Test1

End Sub
Private Sub Form_Error(Data Err As Integer, Response As Integer)
MsgBox "Error Dataerr " & DataErr
MsgBox "Error Dirty " & Me.Dirty
MsgBox "Error New Record " & Me.NewRecord
MsgBox "Error test1 = " & Me.Test1

'No can do
'If DataErr = 2169 Then Me.Dirty = False

Response = acDataErrContin ue
End Sub
Private Sub Form_Unload(Can cel As Integer)
If Not blnX Then
MsgBox "Unload Dirty " & Me.Dirty
MsgBox "Unload New Record " & Me.NewRecord
MsgBox "Unload test1 = " & Me.Test1

'Cancel does absolutely nothing because the code
'doesn't even execute before the new record
'with data is wiped out.
Cancel = True
blnX = True
End If
End Sub

[Salad]

Allen Browne wrote:

No idea how that relates to the OP's q.

I may have misunderstood the following:
"How should I deal with the situation when the User is working on a
NewRecord and (supposedly) has filled in all the required fields and
then hits the Close Button before hitting the Save button?"

I figured the Close button is the X button on the form's caption bar
next to the Min/Restore buttons instead of a oommand button on the form
with the caption Close. It a user presses the X (close) button a
BeforeUpdate event will fire but is ignored and unless the record
already exists (not an newrecord) it will be lost.

[David W. Fenton]

Salad <oi*@vinegar.co m> wrote in
news:g0******** *******@newsrea d2.news.pas.ear thlink.net:

Allen Browne wrote:

No idea how that relates to the OP's q.

I may have misunderstood the following:
"How should I deal with the situation when the User is working on
a NewRecord and (supposedly) has filled in all the required fields
and then hits the Close Button before hitting the Save button?"

I figured the Close button is the X button on the form's caption
bar next to the Min/Restore buttons instead of a oommand button on
the form with the caption Close. It a user presses the X (close)
button a BeforeUpdate event will fire but is ignored and unless
the record already exists (not an newrecord) it will be lost.

But this is a classic known bug and it is handled by forcing the
save in the form's OnClose event, or getting rid of the form's Close
button and supplying your own that forces Me.Dirty = False before
closing the forme, which should throw errors if there are required
fields not filled out.

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

[Salad]

David W. Fenton wrote:

Salad <oi*@vinegar.co m> wrote in
news:g0******** *******@newsrea d2.news.pas.ear thlink.net:

Allen Browne wrote:

No idea how that relates to the OP's q.

I may have misunderstood the following:
"How should I deal with the situation when the User is working on
a NewRecord and (supposedly) has filled in all the required fields
and then hits the Close Button before hitting the Save button?"

I figured the Close button is the X button on the form's caption
bar next to the Min/Restore buttons instead of a oommand button on
the form with the caption Close. It a user presses the X (close)
button a BeforeUpdate event will fire but is ignored and unless
the record already exists (not an newrecord) it will be lost.

But this is a classic known bug and it is handled by forcing the
save in the form's OnClose event, or getting rid of the form's Close
button and supplying your own that forces Me.Dirty = False before
closing the forme, which should throw errors if there are required
fields not filled out.

Hmmmm...I wonder if this bug will be removed in the new version of
Access. Perhaps it's been around so long it's considered a feature.

The problem that I see is that the form has "unloaded" prior to hitting
the OnClose event and if a BeforeUpdate event occurred that Canceled,
the reset of the Autonumber/NewRecord will occur prior to that Close event.

Maybe by using a Type/EndType construct in the OnError event to ask the
user whether or not to save could work by canceling the Unload and
refilling the fields.

[David W. Fenton]

Salad <oi*@vinegar.co m> wrote in
news:HD******** ********@newsre ad1.news.pas.ea rthlink.net:

David W. Fenton wrote:

Salad <oi*@vinegar.co m> wrote in
news:g0******** *******@newsrea d2.news.pas.ear thlink.net:

Allen Browne wrote:

No idea how that relates to the OP's q.

I may have misunderstood the following:
"How should I deal with the situation when the User is working ona NewRecord and (supposedly) has filled in all the required
fields and then hits the Close Button before hitting the Save
button?"

I figured the Close button is the X button on the form's caption
bar next to the Min/Restore buttons instead of a oommand button
on the form with the caption Close. It a user presses the X
(close) button a BeforeUpdate event will fire but is ignored and
unless the record already exists (not an newrecord) it will be
lost.

But this is a classic known bug and it is handled by forcing the
save in the form's OnClose event, or getting rid of the form's
Close button and supplying your own that forces Me.Dirty = False
before closing the forme, which should throw errors if there are
required fields not filled out.

Hmmmm...I wonder if this bug will be removed in the new version

of Access. Perhaps it's been around so long it's considered a
feature.

The problem that I see is that the form has "unloaded" prior to
hitting the OnClose event and if a BeforeUpdate event occurred
that Canceled, the reset of the Autonumber/NewRecord will occur
prior to that Close event.

Maybe by using a Type/EndType construct in the OnError event to
ask the user whether or not to save could work by canceling the
Unload and refilling the fields.

Seems to me it's just much easier to avoid using the built-in close
button, and just write your own code that won't close the form
until
you know the record has been saved in a proper state.

That's the way I approach deleting records -- I never allow
deletions through the Access UI, because you cam't depend on the
OnDeleteConfirm event to fire (if SetWarnings is off) and because
by
the time it fires, the record is already gone, so you're forced to
cache the data *before* the delet in order to provide a meaningful
"Do you want to delete the record for 'David W. Fenton"?"
confirmation message.

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

[Salad]

David W. Fenton wrote:

Salad <oi*@vinegar.co m> wrote in
news:HD******** ********@newsre ad1.news.pas.ea rthlink.net:

David W. Fenton wrote:

Salad <oi*@vinegar.co m> wrote in
news:g0***** **********@news read2.news.pas. earthlink.net:

Allen Browne wrote:
>No idea how that relates to the OP's q.

I may have misunderstood the following:
"How should I deal with the situation when the User is working
on
a NewRecord and (supposedly) has filled in all the required
fields and then hits the Close Button before hitting the Save
button?"

I figured the Close button is the X button on the form's caption
bar next to the Min/Restore buttons instead of a oommand button
on the form with the caption Close. It a user presses the X
(close) button a BeforeUpdate event will fire but is ignored and
unless the record already exists (not an newrecord) it will be
lost.
But this is a classic known bug and it is handled by forcing the
save in the form's OnClose event, or getting rid of the form's
Close button and supplying your own that forces Me.Dirty = False
before closing the forme, which should throw errors if there are
required fields not filled out.

Hmmmm...I wonder if this bug will be removed in the new version

of

Access. Perhaps it's been around so long it's considered a
feature.

The problem that I see is that the form has "unloaded" prior to
hitting the OnClose event and if a BeforeUpdate event occurred
that Canceled, the reset of the Autonumber/NewRecord will occur
prior to that Close event.

Maybe by using a Type/EndType construct in the OnError event to
ask the user whether or not to save could work by canceling the
Unload and refilling the fields.

Seems to me it's just much easier to avoid using the built-in close
button, and just write your own code that won't close the form
until
you know the record has been saved in a proper state.

So many people are used to the min/max/close window buttons that yes, a
form without a close button can be used but I like giving ops whatever
options they want.

If MS knows about this, I think enough versions have gone by that they
can fix it.

That's the way I approach deleting records -- I never allow
deletions through the Access UI, because you cam't depend on the
OnDeleteConfirm event to fire (if SetWarnings is off) and because
by
the time it fires, the record is already gone, so you're forced to
cache the data *before* the delet in order to provide a meaningful
"Do you want to delete the record for 'David W. Fenton"?"
confirmation message.

Hmmm....I Cancel deletes if the op declines. I've not experienced this
issue.

[David W. Fenton]

Salad <oi*@vinegar.co m> wrote in
news:LN******** *********@newsr ead3.news.pas.e arthlink.net:

David W. Fenton wrote:
[]

Seems to me it's just much easier to avoid using the built-in
close button, and just write your own code that won't close the
form until
you know the record has been saved in a proper state.

So many people are used to the min/max/close window buttons that
yes, a form without a close button can be used but I like giving
ops whatever options they want.

You can fake a title bar and a close button. I think the Marlett
font comes with all versions of Outlook and/or Office, and it has
an
X that works great for replicating the x button. The close button
on
each these forms:

http://www.dfenton.com/DFA/examples/assignment.gif
http://www.dfenton.com/DFA/examples/c_1summ.gif
http://www.dfenton.com/DFA/examples/Activities.gif

is fake. That's how I got the custom-looking titlebar.
If MS knows about this, I think enough versions have gone by that
they can fix it.

I think the reliability of forms as editing tools started a general
decline with the release of A2K.

That's the way I approach deleting records -- I never allow
deletions through the Access UI, because you cam't depend on the
OnDeleteConfirm event to fire (if SetWarnings is off) and because by
the time it fires, the record is already gone, so you're forced
to cache the data *before* the delet in order to provide a
meaningful "Do you want to delete the record for 'David W.
Fenton"?" confirmation message.

Hmmm....I Cancel deletes if the op declines. I've not

? experienced this issue.

But if SetWarnings is off, the OnDeleteConfirm event never happens.
If it does and you set Cancel = True, then the record reappears,
when it was previously gone.

Both of these are things I consider unacceptable in a
professional-looking application, so I avoid them entirely by not
using any of the delete events.

I believe that is also the solution for the default values problem.

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