Form "On Dirty" Event

[Guest]

In Access 2000, modifying data in a text box bound to a table with VBA code
would cause the forms "on dirty" event to fire.

I just ported an application from Access 2000 over to Access 2003 and have
discovered, to my dismay, that modifying data using VBA code causes the forms
"dirty" attribute to be set to true but it does not cause the forms "on
dirty" event to fire.

I have only been able to trigger the even by keying data myself; I even
tried using SENDKEYS in VBA to see if this would trigger the event but it
would not.

Has anyone found a fix for this lack of consistency between Access 2000 and
Access 2003? I hate to have to re-engineer my application that relies on vba
code modification of data to trigger the event.

Thanks

 

[Marshall Barton]

In Access 2000, modifying data in a text box bound to a table with VBA code
would cause the forms "on dirty" event to fire.

I just ported an application from Access 2000 over to Access 2003 and have
discovered, to my dismay, that modifying data using VBA code causes the forms
"dirty" attribute to be set to true but it does not cause the forms "on
dirty" event to fire.

I have only been able to trigger the even by keying data myself; I even
tried using SENDKEYS in VBA to see if this would trigger the event but it
would not.

Has anyone found a fix for this lack of consistency between Access 2000 and
Access 2003? I hate to have to re-engineer my application that relies on vba
code modification of data to trigger the event.

Form events are never triggered by actions in VBA code. It
would be a complete disaster if every control assignment in
a VBA procedure caused a potential cascade of events to
occur before the next line of code could be executed.

Since you are using VBA code to set the control's value, it
is trivially easy to have the same VBA procedure execute
whatever other procedure (event ot otherwise) you want to
run simply by calling it. E.g.

Me.textbox = something
Me.Form_Dirty

 

[Dirk Goldgar]

Form events are never triggered by actions in VBA code. It
would be a complete disaster if every control assignment in
a VBA procedure caused a potential cascade of events to
occur before the next line of code could be executed.

However, I just tested and, contrary to what it says in the A2K help
file, assigning to a bound control's Value property does fire the form's
Dirty event in A2K. In A2K2, it does not. I'd say that's a bug in A2K,
since the help file says it shouldn't.

 

[Marshall Barton]

However, I just tested and, contrary to what it says in the A2K help
file, assigning to a bound control's Value property does fire the form's
Dirty event in A2K. In A2K2, it does not. I'd say that's a bug in A2K,
since the help file says it shouldn't.

I'll say that was a bug too. Maybe it was the one that made
me decide to never use A2K ;-)

Note that, in one of Paul's many other threads on this
question, I did remember that setting the Text property does
trigger events from VBA code.

 

[Dirk Goldgar]

Note that, in one of Paul's many other threads on this
question, I did remember that setting the Text property does
trigger events from VBA code.

Yes, good idea. Of course, he'll have to SetFocus to the control in
order to do that.