Control's AfterUpdate Event

[ions]

Dear Access Expert.

I wanted to confirm that the only time a Control's AfterUpdate event is fired is if you manually dirty the control and then you step out of it.

I noticed changing the value of the control through VBA doesn't call the AfterUpdate event. How come? The logical thing in my mind is to call it even if the control is dirtied via VBA.

Thank you.

 

[Galaxiom]

VBA bypasses the events.

If necessary, call the AfterUpdate procedure at the end of the VBA you use to update the control.

However it is a better practice to call a separate procedure that is also called by the AfterUpdate event rather than directly call the AfterUpdate Event Procedure itself.

 

[ions]

Thank you.

Can I conclude that control's events are Bypassed by VBA but the Form's Events are NOT Bypassed.

For example, the VBA statement If Me.dirty then Me.Dirty = False does call the Form's Before Update event.

Thank you

 

[vbaInet]

Setting the Value of a control will not call the After Update event because that's one way of "bypassing" control events.

To simulate a user typing into the textbox and moving away from it - which will cause the After Update event to fire - you will need to use the Text property and set focus elsewhere. This will cause the After Update event to fire.

E.g.

Me.txtBox.SetFocus
Me.txtBox.Text = "some value"
Me.CommandButton.SetFocus

This will cause the After Update event of the control txtBox to fire.

 

[missinglinq]

Can I conclude that control's events are Bypassed by VBA but the Form's Events are NOT Bypassed.

For example, the VBA statement If Me.dirty then Me.Dirty = False does call the Form's Before Update event.

Yes, If Me.dirty then Me.Dirty = False does pop the Form_BeforeUpdate event.

And populating a control through code, while it doesn't fire any events connected to the control, does cause the form to become Dirty.

On the other hand, a field/control that has a Default Value set at table/form level, while it appears to populate the the control when a new record is invoked doesn't Dirty the form!

Access is a model of clarity, isn't it!

Linq ;0)>

 

[ions]

Thank you to all. You all made some very good points.

 

[DCrake]

There is nothing stopping you from forcing the after update event from another control, such as

..Do something here and now
TextBox_AfterUpdate()

Or

CmdButton_Click()

 

[ions]

I wanted to create an infinite loop.


Private Sub CustomerName_AfterUpdate()

Me.Command2.SetFocus
Me.CustomerName.SetFocus
Me.CustomerName = "JOE"
Me.Command2.SetFocus

End Sub

According to vbaInet's post the above should produce an infinite loop when I dirty the CustomerName control and step out of it.

How come it didn't?

Thanks

 

[ions]

This obviously produced the Infinite Loop

Private Sub CustomerName_AfterUpdate()

Call CustomerName_AfterUpdate

End Sub

 

[vbaInet]

Private Sub CustomerName_AfterUpdate()

Me.Command2.SetFocus <-- Not needed
Me.CustomerName.SetFocus
Me.CustomerName.Text = "JOE"
Me.Command2.SetFocus

End Sub

But like GalaxiomAtHome and DCrake mentioned, you can always call the After Update event when you set the Value.

What do you mean by infinite loop? In programming terms an infinite loop is something that programmers normally avoid and from the looks of things I don't think you're trying to creative a recursive call either.

 

[ions]

vbaInet.

I am just trying to understand triggers for events and why it was decided to ByPass control events when using VBA. I am just playing around and not doing useful things.

Your code does work.

Thanks.

 

[Galaxiom]

I am just trying to understand triggers for events and why it was decided to ByPass control events when using VBA.

The event actions can always be added to a procedure but if it was fired automatically the developer would not have the choice to not trigger it.

 

[ions]

Galaxiom, that's true.

But then the reverse question is valid. Why does VBA automatically trigger FORM events and NOT give us the choice?

For example why does DoCmd.Close trigger the form events like Unload, Close. Why are we not given a choice for Form events but are given a choice for Control events?

Perhaps, this is becoming too philosophical. I was just really surprised that the Control events don't fire but the Form events do with VBA.

Thanks

 

[vbaInet]

The Form is the parent object of the controls so it's necessary that it fires its own events whether you do it through code or not.

You have the option of "disabling" it if you want to:

Me.txtbox.Value = "some value"
Me.AfterUpdate = ""   [COLOR=Blue]<-- this will ensure that the form's After Update event is silenced[/COLOR]
DoCmd.RunCommand acCmdSaveRecord
Me.AfterUpdate = "[Event Procedure]"   [COLOR=Blue]<-- re-enable the event[/COLOR]

This same logic applies to any event. Use wisely.

 

[ions]

Interesting.

Thanks vbaInet.