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

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

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

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

Yes, I can reproduce the results I posted above.

@billpars
Change() events are notoriously fickle
And with LimitToList=  True, I have a hard time imagining what you'd want to use Change() for

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?

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

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

@bill
so, you are saying that my post at http:#a40683730 is not enough explanation.

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

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

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

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

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

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.