When does record become dirty?

[alex]

When does record become dirty?

Hello,

I posted a question about the dirty property in the immediate window…I
think this question is different, so that’s why I’m posting it here.

In the On Dirty event of all my text/combo boxes I call this function
(=IsRecordDirty()):

Private Function IsRecordDirty()
Debug.Print Me.Dirty
If Me.Dirty Then
Me.cmdUndo.Enabled = True
Me.cmdSave.Enabled = True
Else
Me.cmdUndo.Enabled = False
Me.cmdSave.Enabled = False
End If
End Function

When I open the form, click on a textbox, and type data, the On Dirty
event of that control fires, but fires Me.Dirty = False.

I then click a second textbox, type data, the On Dirty event of that
control fires Me.Dirty = True.

This happens every single time…I don’t understand why the record does
not become dirty until I (1) click a control and type data, (2) click
a second control and type data (now causing the record to dirty).

Any help as to what I’m doing wrong would be appreciated!
Thanks,
alex

 

[Dirk Goldgar]

The form's Dirty property becomes True when a modification to a bound
control is actually committed -- stored in the bound field of the form's
recordset. If you modify a control's value, that modification is not
committed until you leave the control, leave the record, or close the form.
Editing a bound control fires the control's Dirty *event* (and the form's
Dirty event), but the record doesn't actually become dirty until you move on
to the next control, or otherwise do something to commit the edit.

I don't understand why you are using the Dirty events of all your text/combo
boxes, rather than just using the Dirty event of the form itself. Wouldn't
that be simpler?

--
Dirk Goldgar, MS Access MVP
Access tips: www.datagnostics.com/tips.html

(please reply to the newsgroup)


When does record become dirty?

Hello,

I posted a question about the dirty property in the immediate window…I
think this question is different, so that’s why I’m posting it here.

In the On Dirty event of all my text/combo boxes I call this function
(=IsRecordDirty()):

Private Function IsRecordDirty()
Debug.Print Me.Dirty
If Me.Dirty Then
Me.cmdUndo.Enabled = True
Me.cmdSave.Enabled = True
Else
Me.cmdUndo.Enabled = False
Me.cmdSave.Enabled = False
End If
End Function

When I open the form, click on a textbox, and type data, the On Dirty
event of that control fires, but fires Me.Dirty = False.

I then click a second textbox, type data, the On Dirty event of that
control fires Me.Dirty = True.

This happens every single time…I don’t understand why the record does
not become dirty until I (1) click a control and type data, (2) click
a second control and type data (now causing the record to dirty).

Any help as to what I’m doing wrong would be appreciated!
Thanks,
alex

 

[alex]

The form's Dirty property becomes True when a modification to a bound
control is actually committed -- stored in the bound field of the form's
recordset.  If you modify a control's value, that modification is not
committed until you leave the control, leave the record, or close the form.
Editing a bound control fires the control's Dirty *event* (and the form's
Dirty event), but the record doesn't actually become dirty until you moveon
to the next control, or otherwise do something to commit the edit.

I don't understand why you are using the Dirty events of all your text/combo
boxes, rather than just using the Dirty event of the form itself.  Wouldn't
that be simpler?

--
Dirk Goldgar, MS Access MVP
Access tips:www.datagnostics.com/tips.html

(please reply to the newsgroup)


When does record become dirty?

Hello,

I posted a question about the dirty property in the immediate window I
think this question is different, so that s why I m posting it here.

In the On Dirty event of all my text/combo boxes I call this function
(=IsRecordDirty()):

Private Function IsRecordDirty()
Debug.Print Me.Dirty
If Me.Dirty Then
    Me.cmdUndo.Enabled = True
    Me.cmdSave.Enabled = True
Else
    Me.cmdUndo.Enabled = False
    Me.cmdSave.Enabled = False
End If
End Function

When I open the form, click on a textbox, and type data, the On Dirty
event of that control fires, but fires Me.Dirty = False.

I then click a second textbox, type data, the On Dirty event of that
control fires Me.Dirty = True.

This happens every single time I don t understand why the record does
not become dirty until I (1) click a control and type data, (2) click
a second control and type data (now causing the record to dirty).

Any help as to what I m doing wrong would be appreciated!
Thanks,
alex

Dirk,

Thanks for responding; I appreciate it.

Yes, it would probably be easier to use the form’s Dirty Event, but I
can’t get it to fire (or fire true).

What I’m trying to do is enable a Save and Undo button when the record
becomes dirty. I know the record is automatically saved when the next
record is displayed, but I’d like to give the user an option to hit
the Save button or highlight the Undo button when it can actually undo
something!

How can I use the Form’s On Dirty event to test whether the form is
actually dirty (after a control receives a new value and before the
commitment you mentioned)?

Thanks,
alex

 

[Dirk Goldgar]

Yes, it would probably be easier to use the form’s Dirty Event, but I can’t
get it to fire (or fire true).

What I’m trying to do is enable a Save and Undo button when the record
becomes dirty. I know the record is automatically saved when the next
record is displayed, but I’d like to give the user an option to hit the
Save button or highlight the Undo button when it can actually undo
something!

How can I use the Form’s On Dirty event to test whether the form is
actually dirty (after a control receives a new value and before the
commitment you mentioned)?

Why do you need to test whether the form is dirty in the Dirty event? If
the Dirty event fires, then some bound control has been changed. For your
purposes, it doesn't matter whether the modified control value has been
committed or not -- it *will* be, unless the user "undoes it". Therefore,
all you need to do in the Dirty event is enable your Undo and Save buttons:

Private Sub Form_Dirty()

Me.cmdUndo.Enabled = True
Me.cmdSave.Enabled = True

End Sub

Of course, you will want to disable those buttons in the form's Current
event and its AfterUpdate event:

Private Sub Form_AfterUpdate()

Me.cmdUndo.Enabled = False
Me.cmdSave.Enabled = False

End Sub

Private Sub Form_Current()

Me.cmdUndo.Enabled = False
Me.cmdSave.Enabled = False

End Sub

Maybe I'm missing something, but I don't see what else you might need to do.

 

[alex]

Why do you need to test whether the form is dirty in the Dirty event?  If
the Dirty event fires, then some bound control has been changed.  For your
purposes, it doesn't matter whether the modified control value has been
committed or not -- it *will* be, unless the user "undoes it".  Therefore,
all you need to do in the Dirty event is enable your Undo and Save buttons:

    Private Sub Form_Dirty()

        Me.cmdUndo.Enabled = True
        Me.cmdSave.Enabled = True

    End Sub

Of course, you will want to disable those buttons in the form's Current
event and its AfterUpdate event:

    Private Sub Form_AfterUpdate()

        Me.cmdUndo.Enabled = False
        Me.cmdSave.Enabled = False

    End Sub

    Private Sub Form_Current()

        Me.cmdUndo.Enabled = False
        Me.cmdSave.Enabled = False

    End Sub

Maybe I'm missing something, but I don't see what else you might need to do.

--
Dirk Goldgar, MS Access MVP
Access tips:www.datagnostics.com/tips.html

(please reply to the newsgroup)

Dirk,

I must not understand the Dirty Property...

I place this code in my form module and it never fires...ever:

Private Sub Form_Dirty(Cancel As Integer)

Me.cmdUndo.Enabled = True
Me.cmdSave.Enabled = True
MsgBox "form_dirty fired"

End Sub

I'm guessing that if I change the value of my controls the dirty event
should fire. I must have code somewhere that is saving the form
automatically thereby not allowing the form's dirty event to fire...

I think we're on the same page. As a side note: What can I do to the
form that in your opinion would cause the form's dirty event to fire?

Thanks,
alex

 

[Dirk Goldgar]

I must not understand the Dirty Property...

I place this code in my form module and it never fires...ever:

Private Sub Form_Dirty(Cancel As Integer)

Me.cmdUndo.Enabled = True
Me.cmdSave.Enabled = True
MsgBox "form_dirty fired"

End Sub

I'm guessing that if I change the value of my controls the dirty event
should fire. I must have code somewhere that is saving the form
automatically thereby not allowing the form's dirty event to fire...

More likely, you have code that is dirtying the form programmatically. The
Dirty event only fires when the form is first dirtied by user action (or by
assigning to a bound control's Text property). If you have code or a macro
that assigns a value to a bound control before the user makes his own
changes, then the form is already dirty when the user makes a change, and so
the Dirty event doesn't fire.

 

[John W. Vinson]

What I’m trying to do is enable a Save and Undo button when the record
becomes dirty. I know the record is automatically saved when the next
record is displayed, but I’d like to give the user an option to hit
the Save button or highlight the Undo button when it can actually undo
something!

PMFJI, but I don't think the Dirty event is appropriate for this purpose. The
Form's BeforeUpdate event fires right before the record is written to disk,
and is cancellable. You could use code like

Private Sub Form_BeforeUpdate(Cancel as Integer)
Dim iAns As Integer
iAns = MsgBox("Click OK to save, Cancel to cancel", vbOKCancel)
If iAns = vbCancel Then
Cancel = True
Me.Undo
End If
End Sub

However, in my experience, users will ABSOLUTELY HATE this: "yes, dammit, I
did want to save the record, that's why I entered it!!!!" and will just
automatically click OK. Training users that "when you enter data, it enters
the data into the table" is easier all around.

 

[Dirk Goldgar]

PMFJI, but I don't think the Dirty event is appropriate for this purpose.
The
Form's BeforeUpdate event fires right before the record is written to
disk,
and is cancellable. You could use code like

I don't think I agree with you, John, about what Alex is trying to do. As I
understand it, he's not putting up a confirmation dialog, but just having
Save/Undo buttons be enabled only when the form is dirty. In other words,
the buttons should be disabled until a record has been modified, at which
point they should be enabled. For that purpose, I think the Dirty event is
the event to use.

To my mind, this is good UI design, making it clear to the user when a
particular button is operable. Of course, there is no need for a Save
button, and I wouldn't have one on my own forms. But an Undo button? Sure,
why not?

 

[alex]

I don't think I agree with you, John, about what Alex is trying to do.  As I
understand it, he's not putting up a confirmation dialog, but just having
Save/Undo buttons be enabled only when the form is dirty.  In other words,
the buttons should be disabled until a record has been modified, at which
point they should be enabled.  For that purpose, I think the Dirty event is
the event to use.

To my mind, this is good UI design, making it clear to the user when a
particular button is operable.  Of course, there is no need for a Save
button, and I wouldn't have one on my own forms.  But an Undo button?  Sure,
why not?

--
Dirk Goldgar, MS Access MVP
Access tips:www.datagnostics.com/tips.html

(please reply to the newsgroup)

Dirk,
I'm sure you're right...I'm going to do some testing and post back.
Thanks for the advice about the save button (your advice too John).
I loop through the controls on this form to advise the user when he/
she can leave the record (if certain textboxes are null you can't
create a record). That's where the cmdSave.Enabled comes in
handy...so they know they've got a "complete" record.
alex

 

[John W. Vinson]

As I
understand it, he's not putting up a confirmation dialog, but just having
Save/Undo buttons be enabled only when the form is dirty.

ah... sorry! Quite right.

 

[alex]

ah... sorry! Quite right.

Dirk/John,
I had code that was modifying a bound control and called from the
on_current event. I changed the code and now the form_dirty event
fires. I appreciated the help.
alex