'After Update' behaviour of controls.

[Peter Hallett]

I have a form with an unbound control which can be updated either
programmatically or manually. If the latter, the associated Before and/or
After Update events can be used to run appropriate commands. However, if the
control is updated programmatically, neither of the latter events, nor On
Change, is triggered, meaning that a rather obtuse work-around has to be
invoked. I do not understand this and would like to find a better mechanism
to trigger the required VBA when the displayed content of the control
changes. Could someone please throw some light on the matter?

 

[Dirk Goldgar]

I have a form with an unbound control which can be updated either
programmatically or manually. If the latter, the associated Before and/or
After Update events can be used to run appropriate commands. However, if
the
control is updated programmatically, neither of the latter events, nor On
Change, is triggered, meaning that a rather obtuse work-around has to be
invoked. I do not understand this and would like to find a better
mechanism
to trigger the required VBA when the displayed content of the control
changes. Could someone please throw some light on the matter?

Control events generally fire when their values are modified by user action,
and not when the values are modified programmatically. I've never found
this to be a problem, as when I use code to modify a control, I can also use
code to call the relevant event procedure. For example,

Me.cboSearch = "Doe, John"
Call cboSearch_AfterUpdate

This is complicated slightly when the code that is modifying the control is
on some other form, or a subform. In that case, the event procedure must be
defined as Public, rather than Private as usual, and the call must contain a
reference to the containing form, like this:

With Me.Parent
.cboSearch = "Doe, John"
.cboSearch_AfterUpdate
End With

If you really *must* force the control's events to be fired naturally, you
can set the focus to the control and modify its Text property, like this:

With Me.cboSearch
.SetFocus
.Text = "Doe, John"
End With

That will simulate an update via user action. However, I prefer not to do
this.

 

[Scott McDaniel]

I have a form with an unbound control which can be updated either
programmatically or manually. If the latter, the associated Before and/or
After Update events can be used to run appropriate commands. However, if the
control is updated programmatically, neither of the latter events, nor On
Change, is triggered, meaning that a rather obtuse work-around has to be
invoked. I do not understand this and would like to find a better mechanism
to trigger the required VBA when the displayed content of the control
changes. Could someone please throw some light on the matter?

I don't really see any way around a "dual" process - that is, you call
your data manipulation mechanisms from both the Update/Change events,
and anywhere your code manages data manipulation.

BTW, this is what classes are made for ... if you base your unbound
form on a Class module that represents the data your form handles,
then you can simply call your classes Update or Save function as
needed, and you'd have a "single point of entry", so to speak.

Scott McDaniel
Microsoft Access MVP 2009
www.infotrakker.com

 

[Peter Hallett]

Thanks, Dirk, for your usual helpful response. When I first came across this
phenomenon I thought that it was odd that, whilst a manual input to a control
could be made to trigger an event, an equally obvious change made
programmatically apparently went unnoticed. I have been using work-arounds
of the sort you suggest but it occurred to me that I could well be missing
something. Sadly, it appears not. The thing with Access is that it is
nearly always possible to find ‘another way’ but it is much more difficult to
be sure that you have found the ‘best’ or ‘right’ way (if there is such a
thing). That is when I turn to the forum.

What I have tended to do in these particular cases is to write the required
‘On_Event’ code in a procedure, which I call from the After(or Before)_Update
event associated with the control, and as the final action of the VBA that
carries out the programmed update – associated in the present case with a
command button. As ‘another way’ it works but it looks a bit clumsy.

 

[Peter Hallett]

Scott,

I am grateful for your response. My reply to Dirk Goldgar is much the same
as I would make to you. In the mean time, as one of the older (much older!)
generation of programmers, I learned my craft in a 'classless' society - ie
Assembler. It appears to be time that I mended my ways. I will pursue your
suggestion.

 

[Peter Hallett]

June,

Several minds with a similar thought, it would seem. There appears to be no
'magic bullet' but the one thing that does please me is that, on this
occasion at least, I don't appear to have been overlooking something obvious.

Thanks for your input.