me.dirty (1 Viewer)

[depawl52]

Greetings all.
I have a main form and a subform.

On the mainform, when a user enters data, the "Save Record and Return" Button has the typical code:
If Me.Dirty = True Then
If MsgBox(" Save Changes? ", vbYesNo) = vbYes Then
Me.Dirty = False
Else
Me.Undo
End If
End If
This works fine if data is only entered in the main form. When data is subsequently entered in the subform, the "Save Changes" message box no longer appears,
and the user is returned to the previous form. It seems like the record is saved, but there is no option not to save (if info was entered in error).
I've tried and researched various work arounds but have yet to come up with a solution.

What I'm trying to achieve is:
1) The user enters data in the main form, then saves the record, and gets the option to save or not to save.
2) He/She then enters data in the subform, and once again gets the option to save, or not save the subform data.
3) Then he/she gets returned to the previous form.

Maybe there's a different/better way to approach this problem?

As always thanks in advance for any input.

 

[Pat Hartman]

Prompting to save/not save on every record rapidly becomes annoying to users and they will start blowing by your messages without reading them. Don't do it.

If you want to have more control over saving because your users are actually as stupid and careless as they look or you haven't bothered with sound data validation in the form's BeforeUpdate event, then you need to add save buttons to both the main form and the subform.

The following instructions apply to both the main and the subform. You need buttons and code in BOTH.
1. Create a public variable Dim'd as Boolean in the header of each form to record the push of the save button. Name it bSaveButton
2. In the Current event of the form, set bSaveButton to False
3. In the Click event of the save button, set bSaveButton to True
4. In the BeforeUpdate event of the FORM, check the value in bSaveButton. If the value is False, ask the user if he wants to save. If he clicks No, cancel the update and exit the procedure.
5. In the AfterUpdate event of the form set bSaveButton to False

This allows you to force the user to use the save button but you don't bother him with gratuitous messages when he does the right thing. You only bother him when he does the wrong thing. This is much more effective and does not desensitize the user because you are not bombarding him with messages he doesn't need to see.

You might want to take a look at these videos. The second is only 11 minutes. The first is close to an hour.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk

 

[depawl52]

Prompting to save/not save on every record rapidly becomes annoying to users and they will start blowing by your messages without reading them. Don't do it.

If you want to have more control over saving because your users are actually as stupid and careless as they look or you haven't bothered with sound data validation in the form's BeforeUpdate event, then you need to add save buttons to both the main form and the subform.

The following instructions apply to both the main and the subform. You need buttons and code in BOTH.
1. Create a public variable Dim'd as Boolean in the header of each form to record the push of the save button. Name it bSaveButton
2. In the Current event of the form, set bSaveButton to False
3. In the Click event of the save button, set bSaveButton to True
4. In the BeforeUpdate event of the FORM, check the value in bSaveButton. If the value is False, ask the user if he wants to save. If he clicks No, cancel the update and exit the procedure.
5. In the AfterUpdate event of the form set bSaveButton to False

This allows you to force the user to use the save button but you don't bother him with gratuitous messages when he does the right thing. You only bother him when he does the wrong thing. This is much more effective and does not desensitize the user because you are not bombarding him with messages he doesn't need to see.

You might want to take a look at these videos. The second is only 11 minutes. The first is close to an hour.

Bad Data is Bad for Business #1 and #2

I just added #2 --- that link is further down. It is much shorter than #1. I also added a copy of the database I used for the video. Enjoy:) I created a database to help people to understand how and why to use the Form's BeforeUpdate event to validate data. @Uncle Gizmo and I made a...

www.access-programmers.co.uk

Thanks Pat. That's kind of the way I've been leaning, but my approach is pretty much bungling trial and error to get to the code you provided. Much appreciated.