Will a procedure finish for a form/report/function before another starts?

[twgonder]

I hate to ask this again, I tried once before but people got all confused using terms like synchronous/asynchronous (which should only be used in terms of buss/port communications-clocked or not), multi-tasking and multi-threading, etc.

Without all that confusion, the question is quite simple (I think)
IN ACCESS:


If I have FormA and FormB open, each has a command button that runs some VBA code.
If I press CommandButton1 on FormA, will the VBA procedure finish before I can change focus to FormB (and if not) or before CommandButton2 on Form2 can start running its procedure?

I'm at a point where I need to be sure that FormB's procedures can't run before the procedure for FormA finishes.
I guess it's also fair to ask if there are two command buttons on FormA that the first one will finish before the second can begin.

In other words, will a procedure ALWAYS finish before another procedure can start running?
Or will Access suspend (as in multi-tasking) one process to work on another (and possibly have this happen several times before a procedure finishes)?
Are there any other things that could begin like macros, timers, etc. that could interrupt a running procedure?

We already confirmed, in a prior thread, that common variables in a sub-module can be corrupted by multiple running forms (having worked around that horrible oversight of MS), and I need to make sure the same can't happen with procedures.

Because the procedures terminate so quickly on modern hardware, I haven't been able to devise a reasonable test of this.
Thanks

[orange]

My understanding is that in the set up you describe, the vba associated with commandbutton on formA will run to completion before the second would start. However, if your vba contains a DoEvents, you would release control to "the system" and it may be possible to move to your formB before returning to code after the DoEvents in the FormA commandbutton vba. I don't think FormB would get control, but I do not know for sure. I don't see how formB could get the focus.

[twgonder]

I wrote and posted this a week ago. I don't know what happened.

If someone is interested in testing what happens with two forms,
here's a little diddy that allows one to play with a variety of scenarios.

It's a modified version of the code for the right click problem from here:
Right click throwing an error when multiple or modal forms (accessforums.net)

[isladogs]

Access is single threaded. It can only process one task at a time

If Form A is working on a single task, a task in form B cannot start until the other task is finished.

However if e.g. Form A is running a series of tasks on a loop, Form B can interrupt processing in Form A after each loop.
Using DoEvents or Wait/Sleep or dbIdle.RefreshCache makes it easier to interrupt that code
Form B will then run its own code loop and when completed, control will revert to Form A to complete its own processing

In other words, at any time, you can click a button on one form to interrupt code in the other form when a suitable 'moment' occurs
BUT only one set of code can run at any time