Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

OnDirty event not firing

Status
Not open for further replies.

Eupher

MIS
Jul 18, 2002
1,724
US
I'm working on a database that sends calendar appointments and notes to Groupwise. I'm trying to use the OnDirty event to set a flag which would pop a MsgBox to remind the user to send the event to the calendar if the data has changed. Everything works great except on one particular form - it's a fairly complex bound form, similar in construct to all the others, but for some reason, I cannot get the OnDirty event to fire. The flag is just a Yes/No field in the table. Here's the code:

Code:
Private Sub Form_Dirty(Cancel As Integer)
    Me!GWdirty = True
    'for debugging, to see when the event fires
    MsgBox "Form is now dirty."
End Sub
The idea is if the data has changed and the user tries to close the form without first sending the appointment, he/she gets a little reminder:

Code:
If Me!GWdirty Then
    varMBox = MsgBox("Send this event to the Groupwise calendar?", vbYesNoCancel, "Send to GW?")
    Select Case varMBox
        Case vbYes
            Me!GWdirty = False
            Call SendAppointment(Me)
        Case vbNo
            'do nothing, continue processing
        Case vbCancel
            'return to the form
            Exit Sub
    End Select
End If
Any ideas? Thanks!

Ken S.
 
Can't say I've encountered that, unless there's been some corruption...

But first, you've stated the form is bound. The controls you're altering, are they also bound? I think the on dirty only fires when altering bound controls.

Is the .Dirty property of the form true or false when you test for your GWDirty?

Should it be corruption, I've found the /decompile option to resolve most occurences the last years, here's a step by step thingie Decompile or how to reduce Microsoft Access MDB/MDE size and decrease start-up times

Roy-Vidar
 
Hi Roy,

Yes, the controls in question are bound (there are others on the form that are not).

The form's .dirty state is changing; to test it, I put in a MsgBox as the first line of code on the form's Close button:
Code:
MsgBox "The form's .dirty state is " & Me.dirty
The message box displays True or False depending on whether I've altered any data. But the OnDirty event does not fire.

I will check the link about decompiling. In the interim, I put some code in the OnExit event of the fields that are relevant to the outgoing calendar appointments:
Code:
If Me!SDT.Value <> Me!SDT.OldValue Then
    Me!GWdirty = True
End If
A rather clunky work-around, but okay for now. Thanks for your help.

Ken S.
 
Why not simply replace this:
If Me!GWdirty Then
By this ?
If Me.Dirty Then

Hope This Helps, PH.
Want to get great answers to your Tek-Tips questions? Have a look at FAQ219-2884 or FAQ222-2244
 
PHV,
Because the current dirty state is not necessarily related to the state of the flag. If the user (or my code!) recalcs the form, the changes are written, the dirty state is lost and the reminder prompt won't be executed, even though data is different from when the form was opened. The flag state needs to persist until it is cleared by sending the appointment.

Ken S.
 
Hazy memory, old age ... vague thoughts ... other intrusions ...


Dirty doesn't always fire? Doesn't occur on PROGRAMATICALLY instantiated changes? Better to use After Update of specific controls to set a form level variable and use the close / query close event?





MichaelRed


 
Hi, Michael:
Thanks for your input. These aren't programmatic data changes - OnDirty isn't firing even when typing directly into a bound text box. I was initially planning on setting a public boolean variable but decided I needed a field in the table - there could be legitimate reasons why the user wouldn't send the calendar entry in the current edit session. The OnExit trick mentioned above works fine - it just bugs me why this is occurring. Makes me worry that something more fundamental may be broken.

Ken S.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top