Event form_dirty not occurs

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


"Dirk Goldgar" schrieb im Newsbeitrag
...
"Nhan" wrote in message


In old version, the dirty event is also fired, when a textbox is set
to new value over VB code.

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.

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

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

(please reply to the newsgroup)

"Nhan" wrote in message

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

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)

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.
"Dirk Goldgar" schrieb im Newsbeitrag
...
"Nhan" wrote in message

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

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)

"Nhan" wrote in message

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.

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, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

"Dirk Goldgar" schrieb im Newsbeitrag
...
"Nhan" wrote in message

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?

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.

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" wrote in message

"Dirk Goldgar" schrieb im Newsbeitrag
...
"Nhan" wrote in message

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?

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.

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

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

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 ....

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.

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

(please reply to the newsgroup)