Event form_dirty not occurs

  • Thread starter Thread starter Nhan
  • Start date Start date
N

Nhan

Hi,

I have a form, that is bounded to a table and had form_dirty event
procedure.
But this event doesn't occur at all. Why?
I have checked the property window, Datasource property and event Dirty, all
is OK.

thanks for help
Nhan
 
Nhan said:
Hi,

I have a form, that is bounded to a table and had form_dirty event
procedure.
But this event doesn't occur at all. Why?
I have checked the property window, Datasource property and event
Dirty, all is OK.

thanks for help
Nhan
Click to expand...

The Dirty event won't fire if you have dirtied the form with code, even
if now the form is modified by user action. Could this be the problem?
 
even if now the form is modified by user action
What do you mean? Macros? Not by macros
Could this be the problem?
Click to expand...
The Form is not changed by code, but by keyboard

I am surprised, that an article in MSDN demonstrates, how we can check and
reag dirty property of a form. Why? Does it mean, that we should not use
Form_dirty event?

ACC2000: How to Automatically Detect If a Form Is Being Edited
Q210334

Method 2: Using the Dirty Property in an Expression
1.. Follow steps 1 through 4 in Method 1.


2.. Add a new text box with the following properties to the form:



Name: txtEditModeChange
ControlSource: =[Form].[Dirty] & EditModeChange([Form])
Visible: No 3.. On the View menu, click Code.


4.. Create the following function in the module, and then close the
module:



Function EditModeChange (F As Form) As Variant

If F.Dirty Then
F!btnUndo.Enabled = True
Else
F!btnUndo.Enabled = False
End If

End Function 5.. Set the form's AfterUpdate property to the following event
procedure:



Sub Form_AfterUpdate ()
Me!txtEditModeChange.Requery
End Sub
 
Nhan said:
What do you mean? Macros? Not by macros

The Form is not changed by code, but by keyboard
Click to expand...

Hmm. If the value of a bound control is modified by user action, and
the form is not already dirty, then the Dirty event should fire. If
that's not happening in your case, something peculiar is going on.
I am surprised, that an article in MSDN demonstrates, how we can
check and reag dirty property of a form. Why? Does it mean, that we
should not use Form_dirty event?

ACC2000: How to Automatically Detect If a Form Is Being Edited
Q210334
Click to expand...

The Dirty event and the Dirty property aren't quite the same. The Dirty
property is True whenever the form's record has been modified but not
yet saved, no matter how that modification occurred. The Dirty *event*
fires only when a user action (via the user interface) causes the form
to become dirty or when the Text property of a bound control is changed,
when it wasn't dirty before.
 
again,
this form worked well, then I changed some code, now the dirty event is not
fired. When I let the recordselector visible, I can see that the record is
changed, when I type a character in a textbox, although dirty event is not
fired.
 
Nhan said:
again,
this form worked well, then I changed some code, now the dirty event
is not fired. When I let the recordselector visible, I can see that
the record is changed, when I type a character in a textbox, although
dirty event is not fired.
Click to expand...

The obvious question is, what code did you change?
 
again,
The obvious question is, what code did you change?
Click to expand...
I have changed and add a lot of code and functions, I can't tell you, what.
But the basic function to deactivate and activate buttons, when form is
dirty, is not changed.

In old version, the dirty event is also fired, when a textbox is set to new
value over VB code.
The scenario:
- on a form there is a combobox for articles, when users type a new value
and choose it , notinlist event is fired.
- then the form article will be opened, and the new value from combox will
be filled in the article name Textbox. Now the Dirty event is fired, that
is, what I desire.
 
Have you checked that the "On Dirty" row of the Form's Properties still have
"[Event Procedure]" in the row?

If it has, put a Break on the Sub declaration and trace it. Make sure you
compile the code first in case there is a Compile error somewhere else that
can affect the entire code.
 
Nhan said:
In old version, the dirty event is also fired, when a textbox is set
to new value over VB code.
Click to expand...

That should *not* have happened, unless the old code set the text box's
Text property, rather than its Value property. Setting a control's
Value property in code does not raise the form's Dirty event, but
setting its Text property does -- if the form is not yet dirty, that is.
The scenario:
- on a form there is a combobox for articles, when users type a new
value and choose it , notinlist event is fired.
- then the form article will be opened, and the new value from combox
will be filled in the article name Textbox. Now the Dirty event is
fired, that is, what I desire.
Click to expand...

If your code is currently like this:

DoCmd.OpenForm "Article"
Forms!Article!ArticleName = Me!cboArticle

Try changing it to be like this:

DoCmd.OpenForm "Article"
With Forms!Article!ArticleName
.SetFocus
.Text = Me!cboArticle
End With
 
Van T. Dinh said:
Have you checked that the "On Dirty" row of the Form's Properties still have
"[Event Procedure]" in the row? Yes

If it has, put a Break on the Sub declaration and trace it. Make sure you
compile the code first in case there is a Compile error somewhere else that
can affect the entire code.
Click to expand...

I have done, therefore I knew, that the event is not fired
 
but that was only additional inform. The main problem is, Dirty event is not
fired in reaction on user action
To demonstrate my case.
Following is a modul, Form Tabelle1 is bound to any table, this Form had
Form_Dirty procedure, which prints only a line "dirty".
when sub test runs, the line "dirty" is always printed out.

'**********
'Modul1
Option Compare Database
Option Explicit
Dim frm As Form_Tabelle1
Public Sub test()

Set frm = New Form_Tabelle1
frm.Visible = True
frm.test.Value = "jdjdjdj"

End Sub

'******
'form Tabelle1
Option Compare Database
Option Explicit

Private Sub Form_Dirty(Cancel As Integer)
Debug.Print "dirty"
End Sub
 
Nhan said:
but that was only additional inform. The main problem is, Dirty event
is not fired in reaction on user action
To demonstrate my case.
Following is a modul, Form Tabelle1 is bound to any table, this Form
had Form_Dirty procedure, which prints only a line "dirty".
when sub test runs, the line "dirty" is always printed out.

'**********
'Modul1
Option Compare Database
Option Explicit
Dim frm As Form_Tabelle1
Public Sub test()

Set frm = New Form_Tabelle1
frm.Visible = True
frm.test.Value = "jdjdjdj"

End Sub

'******
'form Tabelle1
Option Compare Database
Option Explicit

Private Sub Form_Dirty(Cancel As Integer)
Debug.Print "dirty"
End Sub
Click to expand...

Up to now I thought you were saying that the Dirty event was not firing
when it should. Now you seem to be saying that it *is* firing when it
shouldn't. Regardless, it doesn't behave that way for me. I created a
new form named "TestDirty", bound to table "My Table" with bound field
"My Field", and I gave it this code module:

'------ start of form's code module ------
Option Compare Database
Option Explicit

Private Sub Form_Dirty(Cancel As Integer)

Debug.Print "Dirty"

End Sub
'------ end of form's code module ------

Then I created the following procedure in a standard module:

'------ start of test procedure code ------
Sub TestDirty()

Dim frm As Form_TestDirty

Set frm = New Form_TestDirty
frm.Visible = True
frm.[My Field].Value = "jdjdjdj"
Stop
frm.Undo

End Sub
'------ end of test procedure code ------

When I ran the test procedure, the line "Dirty" was not printed in the
Immediate window, neither before nor after the breakpoint.

Then I modified the test procedure like this:

'------ start of test procedure code ------
Sub TestDirty()

Dim frm As Form_TestDirty

Set frm = New Form_TestDirty
frm.Visible = True
frm.[My Field].SetFocus
frm.[My Field].Text = "jdjdjdj"
Stop
frm.Undo

End Sub
'------ end of test procedure code ------

When I ran this modified procedure, the line "Dirty" was printed in the
Immediate window before the breakpoint was reached.

So I am seeing behavior that matches what I would expect, and that
doesn't match what you report. Are you sure your test form has no other
code in it?

Have we established what version of Access you're using? I'm testing
with Access 2002, and could test if necessary with Access 97 and 2000,
but if you're using Access 2003, I can't check your results in that
version.
 
My problem is "the Dirty event was not firing, when It should".
My demonstration is only to show, how my old code works (both in VBA and
user action).
My access version = 2000.

Thanks for your help.
Nhan
when it should.
Click to expand...
Dirk Goldgar said:
Nhan said:
but that was only additional inform. The main problem is, Dirty event
is not fired in reaction on user action
To demonstrate my case.
Following is a modul, Form Tabelle1 is bound to any table, this Form
had Form_Dirty procedure, which prints only a line "dirty".
when sub test runs, the line "dirty" is always printed out.

'**********
'Modul1
Option Compare Database
Option Explicit
Dim frm As Form_Tabelle1
Public Sub test()

Set frm = New Form_Tabelle1
frm.Visible = True
frm.test.Value = "jdjdjdj"

End Sub

'******
'form Tabelle1
Option Compare Database
Option Explicit

Private Sub Form_Dirty(Cancel As Integer)
Debug.Print "dirty"
End Sub
Click to expand...

Up to now I thought you were saying that the Dirty event was not firing
when it should. Now you seem to be saying that it *is* firing when it
shouldn't. Regardless, it doesn't behave that way for me. I created a
new form named "TestDirty", bound to table "My Table" with bound field
"My Field", and I gave it this code module:

'------ start of form's code module ------
Option Compare Database
Option Explicit

Private Sub Form_Dirty(Cancel As Integer)

Debug.Print "Dirty"

End Sub
'------ end of form's code module ------

Then I created the following procedure in a standard module:

'------ start of test procedure code ------
Sub TestDirty()

Dim frm As Form_TestDirty

Set frm = New Form_TestDirty
frm.Visible = True
frm.[My Field].Value = "jdjdjdj"
Stop
frm.Undo

End Sub
'------ end of test procedure code ------

When I ran the test procedure, the line "Dirty" was not printed in the
Immediate window, neither before nor after the breakpoint.

Then I modified the test procedure like this:

'------ start of test procedure code ------
Sub TestDirty()

Dim frm As Form_TestDirty

Set frm = New Form_TestDirty
frm.Visible = True
frm.[My Field].SetFocus
frm.[My Field].Text = "jdjdjdj"
Stop
frm.Undo

End Sub
'------ end of test procedure code ------

When I ran this modified procedure, the line "Dirty" was printed in the
Immediate window before the breakpoint was reached.

So I am seeing behavior that matches what I would expect, and that
doesn't match what you report. Are you sure your test form has no other
code in it?

Have we established what version of Access you're using? I'm testing
with Access 2002, and could test if necessary with Access 97 and 2000,
but if you're using Access 2003, I can't check your results in that
version.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)
Click to expand...
 
Nhan said:
My problem is "the Dirty event was not firing, when It should".
My demonstration is only to show, how my old code works (both in VBA
and user action).
My access version = 2000.
Click to expand...

Very interesting. I just tested the same code, the same form, and the
same database in Access 2000, and got different behavior from that in
Access 2002. In my copy of Access 2000 (version 9.0.6926 SP-3), I got
the same behavior you report -- dirtying the form by setting the Value
property of a control raised the form's Dirty event, contrary to the
statement in the help file that it would not. In my copy of Access
2002, the Dirty event was not raised, in accordance with the help file.

So, in at least some service-levels of Access 2000, the Dirty event
doesn't act the way the help file says it should. I guess that, this
being a new event for A2K, there were some bugs in its implementation.
Apparently, your old code did work to raise the Dirty event, but should
not have (according to the help file). Is that code still working as it
used to, or did it stop? Is the new code, that isn't raising the Dirty
event, running in the exact same installation of Access as the old code?

If you want to ensure that the Dirty event does fire in your new
circumstances, set the focus to the control you want to change, and then
set its Text poperty. That should force the Dirty event to fire.
 
Dirk Goldgar said:
So, in at least some service-levels of Access 2000, the Dirty event
doesn't act the way the help file says it should. I guess that, this
being a new event for A2K, there were some bugs in its implementation.
Apparently, your old code did work to raise the Dirty event, but should
not have (according to the help file). Is that code still working as it
used to, or did it stop? Is the new code, that isn't raising the Dirty
event, running in the exact same installation of Access as the old code?
Click to expand...

both dbs (old and new) are running in the same environnment, acc2000 sp3, on
the same system and computer
If you want to ensure that the Dirty event does fire in your new
circumstances, set the focus to the control you want to change, and then
set its Text poperty. That should force the Dirty event to fire.
Click to expand...

and with user action (keyboard action)? That is the main problem. I think
that is a bug of access. I will try it in access XP
The Text property is not so comfortable to use, the control must have focus,
when we set the text value. And I think some controls don't have Text
property, then we must know, which type of control and ....
 
Nhan said:
both dbs (old and new) are running in the same environnment, acc2000
sp3, on the same system and computer


and with user action (keyboard action)? That is the main problem.
Click to expand...

Once more I don't follow you. As far as I can tell, the Dirty event is
raised properly by user action in Access 2000, so long as the form has
not already been dirtied programmatically. I get the impression that
you are dealing with a situation in which you open a form and dirty it
programmatically, and then are expecting the form's Dirty event to fire
when the user types in a text box. That is not going to happen.
I think that is a bug of access. I will try it in access XP
Click to expand...

I think the behavior of Access 2000 that you were seeing before was a
bug, and now you aren't seeing that behavior. I don't know why that bug
is not showing itself now, though.
The Text property is not so comfortable to use, the control must have
focus, when we set the text value. And I think some controls don't
have Text property, then we must know, which type of control and ....
Click to expand...

I agree that using the Text property is cumbersome. I might be able to
give you some specific advice if I knew exactly what you are trying to
achieve in the particular case you're trying to solve now, but obviously
we aren't communicating all that well. I need a very clear statement of
what you want your code and forms to do. Maybe you can avoid using the
Dirty event altogether, if you don't find it behaves the way you want.
 
Back
Top