On Dirty fires but Me.Dirty = False (v2010)

[Rod]

 
Private Sub Form_Dirty(Cancel As Integer)
If Me.Dirty Then
MsgBox "dirty"
Else
MsgBox "clean"
End If
End Sub

The code above reports "clean!" It seems Me.Dirty is set true much later in the cycle of things since if I include a command button to test the state it returns "dirty."



Is this a v2010 bug? I don't remember encountering it in earlier versions.

Has anyone got a workaround?

I can't find anything relevant on the web.

[RuralGuy]

For what purpose are you trying to use the Dirty event?

[Rod]

Hi RG,

I have a common sub procedure that synchronises command buttons with the state of the form; one of the buttons is an 'Undo' button that should be disabled if the form is clean and vice versa. The procedure therefore contains an If Me.Dirty condition.

The procedure is invoked by various events: Current, After Update, etc. including On Dirty. The Me.Dirty condition does not work when the procedure is invoked from the On Dirty event.

OK, that's what I'm doing. I can program around this by duplicating code in the actual On Dirty event handler or simply by allowing the 'Undo' button to be enabled all the time. However that's not really the point; the Dirty property is not set at the correct point in the processing cycle and this can lead to logic errors.

I'm fairly sure this is a recent 'bug.' There are examples on the web similar to the code in my first post purporting to demonstrate the use of the On Dirty event - one of the examples I believe is on a Microsoft site! (I've only had v2010 for a few days - I'm having difficulty activating it but that's another story - so I have not yet had an opportunity to check any of my earlier code.)

I have tried various (nasty) tricks such as toggling the focus to see if I can get the property set - but to no avail. (Forcing Dirty = True in the event handler just causes infinite recursion.)

[RuralGuy]

I have not played much with the Dirty event but it is my understanding that it fires when the recordset first goes dirty. I believe it would be safe to "assume" that Dirty is True or about to be True in the Dirty event so the test for Dirty is redundant and unnecessary.

[RuralGuy]

I just tested MsgBox "Me.Dirty = " Me.Dirty in the OnDirty event in AccessXP and the value is False. It looks to me as though the Dirty Flag has not been set yet in this event and this has been the case for some time.

[Rod]

I believe it would be safe to "assume" that Dirty is True or about to be True in the Dirty event so the test for Dirty is redundant and unnecessary.

"About to be true" is obviously the case!

No I didn't put a test on the Dirty property in the On Dirty event handler; I'm not quite that stupid. My example was purely to show the 'incorrect' setting of the property.

My event handler contains a call to another commonly used procedure that contains the test that was failing. I've rewritten the code and duplicated the relevant statements directly in the On Dirty event handler. I dislike duplication since it means any future change has to be done in more than one place.

Thanks for checking the earlier version. You've saved me a lot of time.