This thread veers towards a practice that I am all too familiar with, and which I now try to avoid as much as I possibly can.
That is, trying to put wads of code into multiple form and control events in order to bypass, or to overcome, or to counteract, or to outwit normal Access behaviors.
I came to this position through my own experiences. I recall one particular pit I dug for myself (and by extension, the client), in which I was writing line after line of code to try to control input and data validation, along with interface display options for what should have been a fairly straightforward scenario. Each new attempt to control some event led to additional unwanted side effects that had to be addressed with yet another layer of code. Finally, in desperation, I started over and let Access standard behaviors do as much of the work as possible, keeping my interventions as light as possible. Faster, more reliable data input soon reappeared. I was able to move to more pressing matters, and also to remove wads of superfluous code. It became what is sometimes referred to as a learning moment for me.
My point is this, asking the control -- a combo box in this instance -- to behave differently from how it was designed by Microsoft may not be the best strategy. Rather than writing code to set focus elsewhere when the user clicks it (which I also question as a strategy anyway), I suggest stepping back and rethinking why you came to the conclusion you needed to override the standard Access behavior in the first place.
What problem is being resolved here? If it is, as you say, a matter of users expecting non-standard behavior, a conversation about expectations and reality might go a long way. If they convince you that a) their work will go faster and more efficiently, or b) that it will avoid common errors or c) they'll like you better, well, maybe it's worth trying to wrestle Access for control of its interface.
An aside into AI might be instructive here as well.
One of the key conditions for successful use of AI is that you must assume the role of Project Manager. When Chatty or Claude or Grok spits out a chunk of code, you can't simply accept it, copy and paste it into your application and move on. You have to evaluate that code for accuracy and fit for purpose. That same responsibility is yours when working with users. Either you are the Project Manager, or the users are a diffuse committee of pseudo project managers. When it comes time to evaluate a solution for accuracy and fit for purpose, "Because we want it that way" is not a valid criteria. (I have a granddaughter who thinks it is, but she's only 3 years old.) Their desires are valuable input into YOUR evaluation, of course. It's just not the final word.
I apologize for the length of this post and the lecture it became.
