Solved Control Events Not Firing After User Action

[TrevsDev]

Questions seem to perennially surface in this and other forums about control events not firing. The most common solution (and, in many contexts, the correct one) is that events are only triggered by user-interaction, not when controls are manipulated by VBA code. However, I have encountered a different situation and solution, one that I think is worth posting about.

I had a form that was working perfectly, but because the Details section was very crowded, I moved some controls into the Header section. When I checked in the VBA IDE, all the event procedure code was still there and was still associated with the control's section within the editor (I.e., it was not being seen as a general procedure unassociated with a control). However, when I tested the form, none of those controls' events could be triggered by my actions.

Solution: When I looked at the Events properties list for any of the affected controls, it was empty.

The controls themselves had lost their connection to the VBA procedures, and I had to relink them one by one, by the following steps:

1. Click the three-dots icon on the property to be relinked
   
   
2. Select the Code Builder option.
   
   
3. Click OK.
   • The code editor window immediately updates to show the pre-existing code, now properly linked to the control.

 

[Pat Hartman]

On the surface, this sounds like a bad idea. What subform record is providing the source for the field that is being show on the main form? You see multiple subform records but only one mainform record and that record can't be showing all the values from all the records in the subform.

If the subform records ALWAYS have the same value for the fields you have moved then the fields should be permanently moved since it sounds like they belong in the main form record rather than in the subform record. But as long as the values can be different in each subform record, this can't be a viable solution.

Please post a sample database with just the mainform/subform and records to populate the two tables so we can examine what you did.

 

[The_Doc_Man]

The controls themselves had lost their connection to the VBA procedures, and I had to relink them one by one, by the following steps:

Your three steps are the same steps you have to follow (almost the same) when you have reason to rename a control that has a bound event. From your findings, we can infer that there is something "behind the scenes" to imply the location of the control (as Detail, Header, or Footer) that isn't necessarily shown when looking at property lists - but it acts as a qualifier.

The only difference between your article and my scenario is if you change the control name, you have to go into the Class Module and update the name into the entry point "Private Sub xxxx_Event" statement. Then do your steps. So your solution makes sense and that final step is merely the GUI re-identifying the entry point by name/location qualifier. It is just that we don't see it because the qualifier isn't emphasized.

This is a conjecture. But it makes sense. We can't know for sure because Access is not Open Source. So I admit I'm guessing. And because we don't have Open Source access to the GUI, all we CAN do is guess.

 

[isladogs]

@TrevsDev
This is a well known issue where event code can get detached from its control
You have clearly described the solution though you can save time by clicking in the property sheet and typing a square bracket ‘[‘ and pressing Enter
Access will automatically autocomplete that as [Event Procedure] and reconnect the code.

@Pat Hartman
Your reply was for a different thread

 

[Josef P.]

The controls themselves had lost their connection to the VBA procedures, and I had to relink them one by one, by the following steps: ...

There is a quick way to do this:
Select the entire code in the form class, cut and paste it again.
Steps: Set Focus to class module -> Ctrl+A -> Ctrl+X -> Ctrl+V
The "connection" between event handler and event properties (OnClick,...) are then set again.

 

[Pat Hartman]

@Pat Hartman
Your reply was for a different thread

I don't think so. I did confuse header with main form in my reply (I was sleep typing) but the issue is the same. There is ONE subform header and n visible records.

You are all addressing what happens when you move the control but have not considered the logic flaw in moving a "many" value to a "one" place. EXACTLY which row's values are showing in the subform header at any given time?

 

[isladogs]

Hmm. There was also no mention of a subform!

 

[Pat Hartman]

Hmm. There was also no mention of a subform!

You're being pretty picky. Are you deliberately choosing to miss the point?

EXACTLY which DETAIL row's values are showing in the header at any given time? If the form is not continuous, then this is not a problem because you never see more than one record at a time. But if the form is not continuous then the post actually makes no sense at all. Just expand the detail section. Why move some controls to the header section when you can just expand the detail section?

 

[isladogs]

No I’m not being picky or missing the point.

The OP made no mention of what type of form is being used. Even if the form is single it may already have filled the screen so that the OP wanted to avoid vertical scrolling. We really don’t know what the setup is, but frankly that isn’t the point of his post.

The issue that the OP raised about detached events is valid. Everyone else responded to his post. Your answer appeared to have nothing to do with that.

 

[Pat Hartman]

I am not arguing about the advice on how to properly move a control. I guess my point is just too subtle because you apparently think moving bound controls arbitrarily from the detail section to the header section is quite OK. I disagree. We can leave it at that.
1. If the form is in single view, there is no reason to move a bound control to the header. Just expand the detail section.
2. If the form is continuous, there will always be confusion regarding which detail item the values are coming from. YOU may know. I may know but does the user know?

 

[isladogs]

Please do not presume to know what I think.
Your point is about as subtle as a sledgehammer and is, in my opinion, of little relevance to the point that the OP was making.

You say we disagree and can leave it at that but then seem to feel it necessary to repeat yourself.

 

[Pat Hartman]

but then seem to feel it necessary to repeat yourself.

Only because rather than disagree with my assessment, you chose to ignore it. And you are still dismissing my concern as irrelevant so are you saying I should just shut up and go away? How arrogant of you. The OP posted the thread suggesting that moving controls from the detail section to the header was a good idea. It is not a good idea if your form is continuous.