Why does AfterUpdate event raise before Change event for Access combobox?

I need to confirm an unexpected (and unintuitive) observation about the order of events for Access comboboxes.

All the documentation I ever read (going way back) regarding the order of events for Access controls says the Change event precedes the AfterUpdate event.

This seems true if the user modifies combobox text (or selects a list item with an arrow key) before moving focus.

If, however, they select a list item with the mouse before moving focus, then the AfterUpdate event appears to raise before the Change event.

The particulars are:
- Windows 7 (64 bit)
- Access 2010
- Unbound form

Also, potentially-relevant combobox properties are:
- Column Count = 1
- Column Heads = False
- Limit To List = True
- Allow Value List Edits = False
- Inherit Value List = False
- Show Only Row Source Values = False
- Auto Expand = True

It does not seem to matter if the Row Source Type of the combobox is Table/Query or Value List.

Is this behavior documented (or common knowledge among Access developers)?  If not, can anyone reproduce/explain it?
billparsAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Nick67Commented:
<singing sesame street>two of these don't usually go together</singing>
- Unbound form
- Limit To List = True

An unbound form, while certainly possible and many folks have used them to great effect, is an unusual beast.
Being unbound, there can be no sane Current event, and many things may not play as intended for a bound form.
All the documentation I ever read (going way back) regarding the order of events for Access controls says the Change event precedes the AfterUpdate event.

That is certainly so for a bound form, but with an unbound form, 'normal' isn't in play.
For giggles, create a dummy table with a single field and a single record.
Bind your unbound form to it.

Does your unwanted behavior go away?
Rey Obrero (Capricorn1)Commented:
if you select an item from the combo box using the mouse the order of events are
1. afterupdate
2. change

using the keyboard by typing a letter or using the arrow keys the order of the event are
1.change
2. afterupdate
billparsAuthor Commented:
Thanks for the quick replies.

Nick: Whether the form is bound or unbound, the behavior is the same.

Rey: I am too slow on the uptake to interpret your post.  Are you independently reproducing my results, citing documentation, reiterating my own observations...?
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Rey Obrero (Capricorn1)Commented:
Yes, I can reproduce the results I posted above.
Nick67Commented:
@billpars
Change() events are notoriously fickle
And with LimitToList=  True, I have a hard time imagining what you'd want to use Change() for
billparsAuthor Commented:
Rey: Thanks for the confirmation.  Was this a surprise to you, or were you already aware of this behavior?  To your knowledge, is it documented or otherwise known (e.g. in online postings)?

Can you (or anyone else) explain it?
Gustav BrockCIOCommented:
Nick is right. You just don't have a need for the OnChange event in this case.

This may be why no one previously seems to have been bothered by the behaviour your report.

/gustav
billparsAuthor Commented:
Nick and Gustav,

Thanks for your insights and willingness to help.

Although I could offer scenarios with which I am sure you would agree that handling both the Change and AfterUpdate events of a combobox is useful, I would prefer to address the behavior, itself, and not stray too far off topic.

I still hope someone can explain, or at least point to some resource (documentation or online posting) that helps make sense of this behavior.

Bill
Rey Obrero (Capricorn1)Commented:
@bill
so, you are saying that my post at http:#a40683730 is not enough explanation.
billparsAuthor Commented:
Rey,

Again, thanks for confirming the behavior.  That certainly is necessary and helpful, but can you *explain* it?  Why would the order of events reverse, based on keyboard vs. mouse?

(My ultimate concern is other real-life situations that could throw the documented order of events out the window, not just for comboboxes, but for other controls as well.)
Nick67Commented:
https://support.office.com/en-ca/article/Order-of-events-for-database-objects-e76fbbfe-6180-4a52-8787-ce86553682f9#bm4
Highly detailed, definitive explanation of the order of events
When you change the text in a text box or in the text box section of a combo box, the Change event occurs. This event occurs whenever the contents of the control change, but before you move the focus to a different control or record (and therefore, before the BeforeUpdate and AfterUpdate events occur). The following sequence of events occurs for each key that you press in a text box or in the text box section of a combo box:

KeyDown arrow KeyPress arrow Dirty arrow Change arrow KeyUp

but note, that's for keyboard events

Watch carefully what happens in the attached sample.
Click the dropdown
Arrow key
The change event fires, the messagebox appears and the new value remains highlighted

Click the dropdown
Click an item
The afterupdate event is fired and the messagebox appears
Look at the new value.  It is NOT highlighted.
Clear the messagebox
The value becomes highlighted and then the Change events fires.
Now click to GoHere.
No event fires!

The takeaway:
While it appears that the order of events is reversed, that is only an appearance.
With keyboard action, a Change event is the only thing occurring.
With a click action, an AfterUpdate event (remember nothing changed any text in the textbox section!) occurs.
However, since you haven't left the control, Access throws back to the control and highlights the value.
THIS is a change, and causes the Change event
When you leave the control to go to GoHere, the present value (what was there AfterUpdate) and the 'new' value (what is highlighted) are the same, therefore no AfterUpdate event is wanted or needed.

The REAL takeaway:
Don't use the Change event!
ChangeAfterUpdate.mdb
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
<<The REAL takeaway:
Don't use the Change event! >>

More that a combo control is strange beast in that it's really two controls wired together; a text control and a list box.

Jim.
billparsAuthor Commented:
Thanks Nick and Gustav for your takes.  Again, I could offer scenarios in which (I am confident) you would agree that handling AfterUpdate *and* Change events makes sense.

(Jim can speak for himself, obviously, but I suspect that his post alludes to the occasional usefulness of the Change event.)

Unfortunately, nobody can explain the behavior, or point to any documentation or other posts that offer insight.

Unless anyone seriously objects, I guess we need to end it here, and I will award points to Rey for at least confirming the behavior….
Nick67Commented:
Unfortunately, nobody can explain the behavior, or point to any documentation or other posts that offer insight.

I did, but I guess you missed it, or didn't play with the sample to watch it in action.
When you change the text in a text box or in the text box section of a combo box, the Change event occurs.
Per the link.

A click event does NOT involve a changing of the text present in the combobox.
It involves the update of the bound value of the combobox.
Hence no Change event initially, but an AfterUpdate event.
Since you haven't left the combobox, however, Access returns the focus to the box to maintain a consistent UI experience and highlights the new value the click selected.
This Access-driven UI event (The change in text displayed and the the highlighting) IS viewed as a Change event, and the Change event then fires.
Hence the 'reversed' order for a click event.  AfterUpdate and then Change.

This is the critical thing, in bold:
When you change the text in a text box or in the text box section of a combo box, the Change event occurs.
A click event doesn't cause the text to change. No Change event.
The AfterUpdate event does cause the text to change, so the a Change event occurs afterward.

This is the expected behavior by design.  You just have to pay attention to WHEN the text is changing.  The Change event follows the changing of the text. Always.  With a combobox, there happens to be a way to change the value before you change the text.

Again, I could offer scenarios in which (I am confident) you would agree that handling AfterUpdate *and* Change events makes sense.
I find that doubtful.  The scope of possibilities for the Change event are so large and so uncertain, given that it is driven by user action, that almost always another event, BeforeUpdate, AfterUpdate, BeforeInsert, Dirty, or KeyUp almost always wind up providing a better user experience.  But hey, your mileage clearly varies, and that's ok.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
billparsAuthor Commented:
Nick,

Again, thanks for your willingness to spend time and effort to help me understand what is happening.  I downloaded your sample and followed your instructions last week, as soon as EE notified me of your post.  You are correct, however, that I missed what you were saying.

From your 3/27 post << Access throws back to the control and highlights the value. THIS is a change, and causes the Change event>> did not make the sense to me that it, obviously, made to you.  My cursory, overworked, and stressed-out takeaway was, "Not following.  Highlighting is NOT change."

Given your post today, I get what you were saying.  Although, ultimately, all of us are guessing, your reasoning seems valid.  The documentation does not explicitly describe what you do, but it does not explicitly contradict it either.  I guess your explanation is as good as any, and I appreciate your tenacity in reiterating it so that I now understand what you meant.

Thanks,
Bill
Nick67Commented:
No problem.
The key is understanding that the Change event fires only for changes to the text of the applicable control.
That is explicitly laid out in the documentation.
So, on a click event, the text of the control is not immediately changed.
But the click changes the value of the control, hence the AfterUpdate.
It is the changing the value of the control that then changes the text as it is displayed, and the Change event fires.

You had wondered at the beginning
Is this behavior documented (or common knowledge among Access developers)?
regarding a paucity of information about the subject.
It is because the Change event is one that will cause you to pull your hair out :0 and generally not used.
Given that it ONLY fires for the changing of the text, and for EVERY changing of the text, there are far too many instances where it doesn't fire when wanted, and fires when not wanted, to make it a generally useful tool.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Office

From novice to tech pro — start learning today.