Me.Dirty is false within Form_Dirty() event! - VBA MS Access 2007

How do you tell if the form is dirty within the OnDirty event (MS Access 2007)? Consider this simple example, I'm calling out to a subroutine to validate some buttons within the Form_Dirty() event.

Private Sub Form_Dirty(Cancel As Integer) MsgBox Me.Dirty ' The above line shows false, which makes the Me.Dirty property about as useful as tits on a bull! Call validateSaveCancelBtn End Sub Private Sub validateSaveCancelBtn() btnCancel.ENABLED = Me.Dirty btnSave.ENABLED = Me.Dirty End Sub 

And please don't tell me to just stick the code from validateSaveCancelBtn() into Form_Dirty() and hard-code it in there. This is not gona work for me as I'm calling into the validateSaveCancelBtn() from other places too, and the actual logic is more complex than what I pasted here.

1 Answer 1

Assuming your form is a bound form, the form is absolutely guaranteed to be dirty on the Form's Dirty Event, although the Me.Dirty property will still be false at this point.

Here's how you work around this weird gotcha.

Private Sub Form_Dirty(Cancel As Integer) Call validateSaveCancelBtn(True) End Sub Public Sub validateSaveCancelBtn(bDirty as Boolean) btnCancel.Enabled = bDirty btnSave.Enabled = bDirty End Sub 

Everywhere else where you call validateSaveCancelBtn, just use this:

Private Sub Form_AfterUpdate() Call validateSaveCancelBtn(Me.Dirty) End Sub 

Purely as a side note

I try to stay away from using the Visible and Enabled properties on Save/New/Cancel/Delete buttons. I find that it's much more foolproof to program the code behind each of those buttons so that it handles a button press differently (and properly) for every possible scenario.

It's true that there is less feedback for the user if those buttons are always visible and enabled, making it appear that you can Save or Cancel even if there is nothing to Save or Cancel. Having said that, consider that Save and Cancel buttons in Access are basically broken right out of the box. Here's why:

1. A new record or changes to a record will be saved when the user closes the form
2. A new record or changes to a record will be saved when a user moves to a subform
3. Because of #2, a Cancel button will not be able to cancel changes on the Main Form once a user has moved to a subform. Neither can a cancel button on a main form cancel changes made to records on a subform because as soon as focus successfully shifts from the subform back to the main form, the subform record has been saved.

I normally show a Save button and leave it visible and enabled all the time. It makes the user feel good to click it, and there's no harm in providing the button. I do actually put code behind it too, but I do not force the user to use the save button since there are other events (as mentioned) that will cause a Save to be fired.

I generally do not provide Cancel buttons because they are "broken" just as soon as you add a subform. I've been involved in numerous discussions about how to provide the user with a Cancel button that can cancel multi-record edits (basically, handle a form and subforms as a transaction). Probably one of the best methods, though still very involving to build, is to use Temporary Tables (basically pseudo-temporary tables, as Access doesn't actually have anything officially called a temporary table) to hold the records being added/edited. Then on the Save Button or on Form Close you have to actually write those records back to the real database. There's much more to it than that, but I'm just trying to give you a rough idea.