Prevent code execution after Click_Event (1 Viewer)

[ironfelix717]

I have been under the impression that a click event was not fireable until any current code execution was complete.

I.e. If a button once then again, the click event cannot be re-fired until execution of the first instance is complete.

Apparently this isn't the case. That is improper and should not even be allowed by design.

---

How do I prevent this and "yield" to VB? Disabling the button is a jenky way of doing this.
Thanks

 

[arnelgp]

add a Form-wise boolean variable, eg:

Option Explicit

Dim bolClicked As Boolean

private sub button_click()
if not bolClicked then
call some_code
end if
end sub


'on same form
private sub some_code()
bolClicked = True
'do whatever in here
'after finishing reset bolClicked
bolClicked = False
end sub

 

[The_Doc_Man]

The Click event is queued up because it is triggered by an I/O interrupt event (I think). Windows passes the I/O event to Access. Access fields the event in order to dispatch it, then queues it up for future execution. The queue holds the event until the previous event code (whatever it is) completes. And if you click faster than the OnClick code can run, you get the dreaded event "double-tap."

I have to agree with arnelgp on this one. Put something in your software to prevent re-entry if it is critical. When I had a SAVE button on my forms, I made the form change state internally so that the SAVE button was disabled until the form got dirty again. I MADE the button become disabled once I used it and it had an effect that I didn't want repeated.

As to whether it should or should not be allowed, we may have a difference of opinion. For example, if I tap the letter "A" real fast and happen to have an "OnChange" event in a textbox on a form that sometimes gets busy as the result of a change, do I not want to see something change the next time I tap a letter?

ALL of the major and most minor Access events are queued because Access is single-threaded for event code. Because of that, an event cannot interrupt another event. (An event handler can CALL another event handler - but cannot interrupt it.) If you cannot interrupt events then to be sure you don't LOSE the event, you must QUEUE the event. Even it is the same event that you are current running at the moment. So the behavior that you decry is actually Access trying desperately to NOT lose your events for you.

 

[Guus2005]

DoEvents is typically a statement that allowes other events to be triggered.
The statement prevents your application from seeming unresponsive. That is why it is used sometimes.
I would remove that statement from your code first if you have any in your code. removing it also speeds things up.

You could disable all controls on your form to prevent any clicking events while the code runs and reenable it when you are done.

Also you could add the "End" statement at the end of the long OnClick event. It clears the callstack and thus preventing the execution of all other events you clicked and added to the callstack. (Never tried it but worth to experiment with it)

HTH

 

[The_Doc_Man]

@ironfelix717 Here is a link to the END statement description that Guus2005 mentions.

End statement (VBA)

Office VBA reference topic

docs.microsoft.com

While I agree with the statement that END could stop event-routine execution, I don't think it is what YOU want because you merely want to stop a specific event (if I have read your complaint correctly). This END statement is more like using a shotgun to kill a fly. You might, indeed, kill that pesky fly - but Holey Moley what a mess you would leave behind.