Variables corrupted when closing all instances of a form, debugger problems too

[twgonder]

I’m back to a variation of the problem that was discussed at https://www.accessforums.net/showthr...094#post507094



After lots of testing of Allen Browne’s method and reviewing Juan Soto’s video, (and spending lots of time in other Google searched solutions), I’m wondering how to manage multiple instance forms to work when closing. Someone may have mentioned that the debugger gets confused with multiple instances of a form running, and I can confirm that that is a gross understatement.

Not only does the debugger get confused, but the closing of one instance seemingly corrupts the variables in another instance. Yes, they share the same VBA code, but either Microsoft forgot to create a separate code instance or there is a bug that allows one instance to corrupt another.

I have a demo, and I’ve tried to close all the open forms using the Allen Browne approach:

colOpenForm.Remove 1

which seems, as best as I can tell from my testing, to bypass all the VBA code for the form i.e. that might handle errors when closing.

So, I tried a different approach with a timer and tempvars to force a close of the forms. At least I can get the forms to close and run some procedures, but I suspect the corruption of an open form’s variables by another form that closed plays havoc with the form closing VBA logic.
Here are the instances of the form:



Then, after pressing F8 on the first stop in the force close procedure, all the forms have their message box pop up (not individually, not each with their own stop—debugger problem) as shown here:





Not only that, the second stop and the breakpoint (shown in blue highlight) are blown past and the forms start to close, but the final form can’t close because it’s variables have been corrupted as shown with the highlight of orange in the immediate window (the print was run twice, the blank line shows the variable Valdt(0,1) has been cleared.

There is nothing in the code that cleared Valdt(0,1). Reset wasn't done while debugging.

I’m in Access 2021, 64 bit on Windows 10.
Can anyone confirm this problem/possible bug, or suggest what I may be doing wrong when closing multiple instances of a form?

[twgonder]

So, I'm guessing some are asking, WTH(ell)?

Here's a sample db that shows the errors.
Instructions are on the Main Menu.
There's a lot of comments inside the VBA too.

I should point out, that very minor changes in the code can make Access run procedures in dramatically different (and nonsensical) ways.

[twgonder]

Also, since this is a very stripped down version of my big app, it's a good time to test again the infamous crashing of Access with just a simple data entry error.
In some versions, entering "a" in My Number (with tab), and then clicking in My Text will crash Access.

[Edgar]

OK, here goes nothing... I opened your database but I'm not sure I'm doing what you expect, could you provide an actual minimal reproducible example for me (us) to better understand the problem?
From my understanding, a minimal reproducible example should consist of

form1:
button1 to open form2
button2 to close all forms
label1 to visualize what happened to the variables

Form2:
label1 to visualize variable1 upon loading the form
label2 to visualize variable2 upon loading the form






The posted database consists of a form with 5 buttons, confusing instructions ("First open this form and then make a change to a record", I have already opened the form, do I have to close it now?), and a radio button to close all forms, of all controls, why a radio button?. There are 3 modules with confusing naming conventions and some other things.

I mean, I do hope others had better luck, but can you provide a simpler example to be able to understand what's going on better? Every time you create a simpler example, you find out if it's a bug or a poor choice from your part, because if it works in the simpler version, then the issue in your larger project is something else.

[Minty]

I will point out a very obvious thing (to me at least).
DoCmd.Close without any parameters could close almost anything that happens to have the focus of Access's attention at the time.

You should always specify what you are trying to close both by type and name.

The normal way I close any form is

DoCmd.Close acForm, Me.Name

Which means I know it's closing the form I called it from.
Now with multiple instances of the same form you would have to be more specific I suspect, although Me. should reference the form it's called from.

I'm always slight suspicious of multiple loaded copies of the same form, it normally strikes me as a poor design choice particularly if record editing is involved, that could be better handled in some other way, but that's purely a personal preference.

[twgonder]

OK, here goes nothing... I opened your database but I'm not sure I'm doing what you expect, could you provide an actual minimal reproducible example for me (us) to better understand the problem?
From my understanding, a minimal reproducible example should consist of

form1:
button1 to open form2
button2 to close all forms
label1 to visualize what happened to the variables

...

The posted database consists of a form with 5 buttons, confusing instructions ("First open this form and then make a change to a record", I have already opened the form, do I have to close it now?), and a radio button to close all forms, of all controls, why a radio button?. There are 3 modules with confusing naming conventions and some other things.

I mean, I do hope others had better luck, but can you provide a simpler example to be able to understand what's going on better? E...

First, thanks for taking the time to review and comment on the thread.

Some overall perspective:
1. It's a stripped down db that is meant to show a particular problem. It is not a "meaningful" application.
2. Only the main menu and MyForm2_2 are working.
3. In this model the Access Form calls its class module which then can call a supporting Form module (used by all forms for generalized routines) named mod_Form
4. All procedures in the class module are named by Microsoft (of course) and normally have a "_" somewhere in the name
5. Procedures I write generally start with a "f" or "s" to indicate function or subroutine, are an abbreviation of the MS names if tied to a procedure for the form and have comments to explain what the procedure does if it's one I named, but that's not too important in this example db because:
6. The purpose is to show multiple instances of a form opening and closing and how the data gets corrupted.
7. If you make any changes to the program, trying to get the order of close correct, or to fix the variable corruption, then as stated in the form help, there will be differences from what I describe here or there (in the provided help/instructions).
8. From past experience with similar db samples given in this forum, results will differ from person to person, based on the version of Access they are running, as such I provided only general guidelines of what to do in the help for MyForm2_2.
9. If there is a particular step in the instruction you don't understand, please copy it here and I'll give more detail.

I'll try to write a simple step by step instruction that work (or don't work in this case) in Access 2021, 64 bit, but it will only get you started if you decide to explore the problem or a solution. And as I just said, you may get different results which would then mess up my instructions. Would a video help? If so, can you see publicly posted files on OneDrive? In the past people stated they had a problem with this.

Instructions:
1. Unzip the Close1.accdb and put it in your testing area.
2. Run the Close1.accdb, it's safe to enable it with the security prompts, it doesn't write to anyplace outside the db tables.
3. Read the instructions that show on the Main Menu when the db starts.
4. Click on the MyForm2_2 command button.
5. Review the basic form and read the instructions that accompany the form on the Main Menu.
6. Double click in the yellow text box and see that you can see the VBA editor and immediate windows.
7. Type "?TestVariable" in the immediate window. Review the result.
8. Type "?Valdt(0,1)" in the immediate window. Review the result.
9. Press F5 and go back to the form window.
10. If you might want to step through the code to get a big picture view of what's going on, go back to the VBA editor, find the procedure named cmbSave_Click() for the class object of MyForm2_2 and put a break point on the line "Call sFrmFtrCmbSave(Me, Valdt)" (yeah, it's a confusing name, but it makes sense in the unstripped db).
11. Go back to the form
12. Change My Text in record 1 to "te1", the record is now dirty.
13. Click on the VBA Save button and step through the code or just F5 to confirm that it runs without any run-time errors of code stops.
14. Go back to the form and change My Text back to "te11" and tab so the form is dirty again.
15. Close the form and check that there are no errors or stops.
16. On the Main Menu, click on MyForm2_2 three times.
17. Click on the Main Menu Force Forms to close option button. Wait a few seconds.
18. Look at the code in the procedure that stopped. Based on your interpretation of how instances should work, you would expect that a F5 (don't do an F5 yet) will result in 1 or 5 more stops.
19. Add a break point in the same procedure that stopped on the statement "DoCmd.Close". You would now expect a pause at the break point.
20. Press F5, and click OK on the three message boxes. You did get three?
21. For me, two forms disappear, without the second stop or the break point happening. A third form remains open.
22. Go to the VBA editor and see if you've been stopped at a statement that tests for corruption in the Valdt(0,1) variable. This is BAD!
23. Go to the immediate window and check "?TestVariable". For me it is set to nothing. This is BAD!
24. Press F5 to continue with the closing of the last form instance. Check that this is the case and then return to the VBA editor.
25. If you wish, search the entire project for "TestVariable" to confirm that there is no reason it should have been cleared.
26. Comment out the statement "End 'No more processing" in the Private Sub Form_Timer() procedure.
27. Clear the option button on the Main Menu.
27. Repeat the steps of opening three forms and then and then closing them with the option button. Can you make sense of the order of things that are running, what forms are closing and when and why code is still running after the last form closes? I can't.

[twgonder]

I will point out a very obvious thing (to me at least).
DoCmd.Close without any parameters could close almost anything that happens to have the focus of Access's attention at the time.

You should always specify what you are trying to close both by type and name.

The normal way I close any form is

DoCmd.Close acForm, Me.Name

Which means I know it's closing the form I called it from.
Now with multiple instances of the same form you would have to be more specific I suspect, although Me. should reference the form it's called from.

I'm always slight suspicious of multiple loaded copies of the same form, it normally strikes me as a poor design choice particularly if record editing is involved, that could be better handled in some other way, but that's purely a personal preference.

I've had problems specifying the DoCmd.Close as you do, it often results in run-time errors. That is why I commented out part of the line in the Form_Timer() procedure. I'll try the different ways of closing to see if I can find one that works reliably. Also, the Me.SetFocus in the same procedure should eliminate any confusion for Access, given that DoCmd.Close arguments are stated by MS to be optional.

As to multiple loaded copies of a form, Juan Soto in the referenced video makes the case for becoming a "ROCKSTAR" by using "spawning". Since I was doing this for the same reason, in another db environment some 40 years ago, I guess that makes me the Chuck Berry of forms? (Uh oh, here comes that Kiss guy in the Super Bowl ad.)

[twgonder]

I tried this change, as suggested, and got an even more spastic result from Access.

[Minty]

Do you know what issuing Me.Setfocus is actually setting focus to?
I'd be really surprised if it's where you think it is.
You can't set focus to a form as such (if a form has no controls on it you can, but that would be a very unusual situation) only a control on a form.

You are already referring to the specific form using Me.Hwnd, as I stated you need to explicitly refer to the form you are on when trying to close it.
I have my doubts that
Docmd.close acForm, "Form2_2" (which is what Me.Name will evaluate as)

knows which "Form2_2" form it is supposed to be closing when there are more than 1 of them open.

As I said I can't ever think of when having multiple forms open in this fashion was actually useful, data entry is generally a single generic process.
Just because you can do something doesn't mean you ought to.
Multiple sub forms of the same intrinsic form yes.

[twgonder]

If you missed the crash thread, and want to test that on your version of Access:

1. Open the Close1.accdb
2. Open the MyForm2_2 form
3. Go to My Number and enter "a" and press tab
4. Click on My Text and be patient.

If you do get a crash, I would appreciate a report back of what version of Access and Windows you are using.

[twgonder]

Do you know what issuing Me.Setfocus is actually setting focus to?
I'd be really surprised if it's where you think it is.
You can't set focus to a form as such (if a form has no controls on it you can, but that would be a very unusual situation) only a control on a form.

You are already referring to the specific form using Me.Hwnd, as I stated you need to explicitly refer to the form you are on when trying to close it.
I have my doubts that
Docmd.close acForm, "Form2_2" (which is what Me.Name will evaluate as)

knows which "Form2_2" form it is supposed to be closing when there are more than 1 of them open.

As I said I can't ever think of when having multiple forms open in this fashion was actually useful, data entry is generally a single generic process.
Just because you can do something doesn't mean you ought to.
Multiple sub forms of the same intrinsic form yes.

Any system I've worked on, other than one produced by Microsoft, when it spawns a process, it sets up a separate work area to avoid the kind of problems you mention and that the sample is experiencing. I would love to know how to properly close the form based on the .hwnd (or anything else). All the samples I've seen use the code I have incorporated (for testing) when opening the Main Menu. I modified the test as I did because that method of closing (using .remove) has its own problems too. To test those, don't set the option button, close the Main Menu with forms open, and then start the Main Menu again.

Here's a simple real-world reason for multiple instances that I've seen handled in dozens of software packages (and that you have probably experienced):
1. Customer A comes into the store and starts an order.
2. Customer A walks back into the shelves to look for something she forgot.
3. Customer A starts a long-winded conversation on her cell phone in the back of the store.
4. Customers B, C and D come to the counter to buy something, but have to wait until Customer A returns and her order is completed.

And yes, I have read the helps on setting focus, In any case, the form would have to be active no matter which control gets focus.

[twgonder]

Here is an interesting one, based on some minor changes to code,
The VBA debugger is sitting at Stop before the form closes, but there aren't any forms open.

[Edgar]

I created this little database that implements Allen Browne's suggestions to use multiple forms at the same time. Much simpler than your sample, and allows to check what's happening without dealing with logic that does not pertain to the issue.

What you do is simple:
1. Open database, form1 opens automatically
2. You have 2 buttons: one to open an instance of form2 / one to close all instances of form2

Whenever you open a form, it gets added to the collection of forms. You can visualize the collection with the listbox of form1.

Why would this help with your issue? because you can double click an item of the listbox and it will close the form with that name, which means you can effectively reference opened forms without interference. Can we use this database as base to solve further problems?

[twgonder]

@ Edgar, thanks for the db, I'm looking it over. First thing I did was double click on the second listed form and got this:

[Edgar]

It works on my end, buddy
haha

Nah, seriously, my computer ignored that piece of code for some reason, can you check with this modification?

Sub CheckCollection()
    Dim listObject As ListBox
    Set listObject = Forms!form1.Form!lstForms
    
    listObject.RowSource = ""
    Dim item As Variant
    For Each item In formCollection
'        listObject.AddItem CStr(item.Caption) & ", " & CStr(item.hwnd)
        listObject.AddItem CStr(item.hwnd)
    Next item
End Sub