Main/sub form close with Close button fail

[twgonder]

I've got a main/subform.
The main form has a Close button, which does pretty much the same as the form's "X" close.



However, if the sub form is dirty, pressing the Close button first initiates the subform's Form_BeforeUpdate procedure.
In that, I can do a Me.undo, which is what I want as my Close button doesn't automatically save the record, it just ditches the changes to the record with a warning (explicit Save required to save a record).

The problem is that when the subform's Form_BeforeUpdate procedure finishes, control doesn't pass to the code for the Close button on the main form.
It's as if the Cancel is set, even though it's not.
Procedure processing just stops at the end of the same subform's Form_BeforeUpdate subroutine.
As a result, the whole close process is left stuck in a corrupted state.

I've tried this code in the sub form's procedure to give it a kick in the pants (thinking maybe one form could call another's procedure):

Forms(fCntl(3, 1)).Form_Close  ' fCntl(3,1) contains the main form's name

but this produces RTE 2465.

Is there another way to do this call to the main form's Form_Close subroutine to keep the whole Close process running?

Note: Using the main form's "X" close, the processing goes straight to the main form's Form_Close procedure and bypasses the subform's Form_BeforeUpdate procedure. This causes the rest of the closing code to run without a problem.

In the image below, You can see the procedures that ran in the yellow Status textboxes.
In the subform, you can see that there isn't any more processing in the subform, the main form also doesn't show the Close_click.

[ranman256]

use: docmd.close acForm , "formname"

[twgonder]

use: docmd.close acForm , "formname"

It took me a minute; I use this in the main form when the Close button clicks:

DoCmd.Close ObjectType:=acForm, ObjectName:=Me.Name

I'm not sure if there is any difference between the two other than the order you can put those arguments.

But in any case, I thought, that won't work because it never gets to the main form, then I channeled your inner explanation,
and I think you mean to add that to the subform. It will take a little time to test with all the form processing combinations.

I'm still curious if formA can "poke" formB to run a procedure. I've got another situation that could use that.
I'm also curious if there is a way, for VBA in a form to read a variable from another form's class module.

[Welshgasman]

I'm also curious if there is a way, for VBA in a form to read a variable from another form's class module.

Use Tempvars?

[twgonder]

Use Tempvars?

There's a whole bunch of array elements I'd like to check at times. So, it makes sense to go straight to the variable object, if there is one.
Plus, there could be more than one form open, and they might stomp all over a common Tempvars.
You quickly get into the c = b = a syndrome. Why have b & c if you can read a? (Gosh, if I only had a $1 for every time I asked that of a junior programmer when reviewing their code)

[twgonder]

@ranman256 # 2

That turned out to be a golden idea. I was thinking the close should happen in the main form.
Adding it also to the subform seems to work.
I had to move some code out of the Close button procedure and into the Form_Close area, but that's a small price to pay.