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

[Edgar]

I didn't quite test your implementation on my database, twgonder

But I did some testing with the idea of removing the test variable and using the .Tag property of the form. Basically, assign something to the .Tag in the same code you instance it, then you can reference it within events. I could not make it work with the Load or the Open events, but I was able to make it work with the Close event. Take a look at the database attached.



Database4-2.accdb

It obviously depends on what you want to do with this variable, but you can place data there and the Close event will pick it up. You can get creative with that, for instance, if you want to store a name, a number and a date, you could store in the Tag something like "Tomas,123,#1/1/2022#" and later retrieve it with Split.

I know it's not great, but hey, it's an idea.

[moke123]

Your dictionary implementation also failed to keep the variable.

What variable? My example was just a short demo how to open and close an instance. Not about to spend hours on an example to cover every aspect. I use form instances extensively in custom classes and oop. I understand them pretty well.

By the way, you also forgot to add code to remove items from the listbox when a user interacts with the built-in close button

The list box is just a visual representation of the object stored in the dictionary and a way to close an individual instance. A simple call in the close event of the form will destroy the object and remove it from the dictionary.

I didn't look at your code Edgar. I suspect that TWG's extensive use of Global Variables is catching up to him.

[Edgar]

What variable? My example was just a short demo how to open and close an instance. Not about to spend hours on an example to cover every aspect. I use form instances extensively in custom classes and oop. I understand them pretty well.

twgonder is trying to use a class scoped variable in his form, he can initialize it but he can not access it from the form_close event. The form_close code does execute but the value in the variable disappears when the form closes by removing its instance from the collection/dictionary. The variable works as expected if the user interacts with the built-in close button.

I didn't look at your code Edgar. I suspect that TWG's extensive use of Global Variables is catching up to him.

That's what we're trying to figure out.

[twgonder]

What variable?

Exactly, you have no idea what was going on in the posts. You just blindly went off and did something and assumed it dealt with what we were doing and having a problem with. I addressed what you missed earlier.

I didn't look at your code Edgar. I suspect that TWG's extensive use of Global Variables is catching up to him.

Even if the global variables were used "extensively" in my code, what in them could possibly cause the closing of an instance to cause other variables to get reset when closing a noninstance form doesn't? Oh, you haven't read the posts yet. You seem very confused on what Edgar wrote and what I wrote and how they are two different programs, created by two different people that manifest the same problems.

So, I'm having variables reset because I'm using global variables, and Edgar's program has the same bugs, what, because he's NOT using global variables?

[twgonder]

I didn't quite test your implementation on my database, twgonder

But I did some testing with the idea of removing the test variable and using the .Tag property of the form. Basically, assign something to the .Tag in the same code you instance it, then you can reference it within events. I could not make it work with the Load or the Open events, but I was able to make it work with the Close event. Take a look at the database attached.

Database4-2.accdb

It obviously depends on what you want to do with this variable, but you can place data there and the Close event will pick it up. You can get creative with that, for instance, if you want to store a name, a number and a date, you could store in the Tag something like "Tomas,123,#1/1/2022#" and later retrieve it with Split.

I know it's not great, but hey, it's an idea.

Thanks for trying, but the TestVariable is only a symptom. The Valdt array and the TestVariable get reset to nothing. I'll have to check, but I assume this means ALL the variables in the form are getting reset. In any case, if the Valdt array gets reset (and it's not a global as one other commenter suspects, however it is local to a module--which I can't see how either one really matters in the problems we see, what, like we now can't use global and private variables?!!! What's next?, can't use static?), which we see it does, then all my logic to properly close the form (it was stripped out to make the sample easier) goes out the window. As you pointed out, and we see in the testing, closing the form with the X or just starting the form from the navigation pane, doesn't exhibit these problems.

Now, here is the key to the exercise from my point of view. I tested the approach of Alan Browne for multiple form instances (Juan Soto calls then "spawning") to see "what's going on here?". I quickly realized that I don't want to use their idea for shutting down the forms, because other forms aren't instanced, and an administrator needs to be able to set an option to shut down ALL open processes running against a BE server, not just the instanced forms. As we saw, there is a problem closing down the forms with internal logic (using the timer). The bug of resetting variables doesn't bother me too much, other than to know that MS hasn't done a good job with this. Either that or the experts aren't giving good advice of how to instance/spawn forms. In the long-run, I'm going with the timer approach for the reason of shutting down everything. But it would be nice if MS fixed both bugs or gave some better advice on how their collection instancing of forms should be used. I'm not holding my breath for that.

[CJ_London]

I think you have to accept that they way you are trying to do it is the wrong way. It's a long time since I've had to mess around with memory management but pretty sure with modern processors, memory management is more efficient and is split - variables in one section of memory, code in another.

Your way, by closing the instance, the variable section is emptied whilst the code section remains until the code has finished executing. You need to set the focus to the form, then close it, then do whatever you want with the collection and listbox - I just utilised your current code to do that

This works for me

Private Sub lstForms_DblClick(Cancel As Integer)


Dim frm As Form


    For Each frm In Forms
        If frm.Caption = lstForms Then
          frm.SetFocus
          DoCmd.Close
        End If
        
    Next
RemoveOneFromCollection CLng(Me.lstForms.Column(0))
CheckCollection


End Sub

[twgonder]

[QUOTE=CJ_London;508323]I think you have to accept that they way you are trying to do it is the wrong way. .../QUOTE]
I'm sorry, not following you here. To which post were you responding? Whose code are you modifying? There's quite a few.

[CJ_London]

database4 - post #18
and as amended by you in post #23

[twgonder]

database4 - post #18
and as amended by you in post #23

From looking at the code, I had my doubts, but I went ahead and put your code into the .accdb in post#25.
It doesn't seem to do anything (other than just loop) from what I can tell.
In my test it didn't fix the Bad variable problem.

I'll attach the db as I modified and tested it.

[CJ_London]

see what the loop is doing - your original file included a date/time in the form2 captions. I removed them (forgot to mention that)

So either remove them
or add the datetime to the collection so you are storing the full name of the form
or modify the if statement to use like or instr or left function to extract just the hwnd part from the form caption

edit: just tested by modifying your latest upload

If lstForms Like frm.Caption & "*" Then

and stop you timer event

See attached

[twgonder]

see what the loop is doing - your original file included a date/time in the form2 captions. I removed them (forgot to mention that)...
and stop you timer event

See attached

I'm not sure, did you make your change to the Close All command button too? Because the corrupted variables remain if that button is used.

Did you have some source that indicated that the age-old Allen Browne approach was wrong?

So, it seems in essence, that you did exactly what I was doing in the timer event for each form with one option button, and made the user double-click each individual line in the listForms textbox in Form 1? You did the same thing in form1 that I (not Edgar) was doing in form2. Which means you are giving Access hundreds of milliseconds to pull its head out to overcome some internal timing bug, while my attempted solution requires that Access run without user interaction/pausing? Or did I miss something?

[CJ_London]

did you make your change to the Close All command button too? Because the corrupted variables remain if that button is used.

No, that still uses your routine. You would need to modify it

Did you have some source that indicated that the age-old Allen Browne approach was wrong?

No - but if it doesn't work, you try a different way

My way involves returning the focus to the form so the variables are not lost until the form is finally closed. Using your method, add a line

debug.print isnull(testvariable)

you will find it returns false (so there is apparently a value in there). Do some more checking an you will find the value is uninitiated - which is not null. My conclusion was the memory where the variables are stored had been freed up

while my attempted solution requires that Access run without user interaction/pausing? Or did I miss something?

suggest change the code in the timer

[twgonder]

No, that still uses your routine. You would need to modify it

No - but if it doesn't work, you try a different way

My way involves returning the focus to the form so the variables are not lost until the form is finally closed. Using your method, add a line

debug.print isnull(testvariable)

you will find it returns false (so there is apparently a value in there). Do some more checking an you will find the value is uninitiated - which is not null. My conclusion was the memory where the variables are stored had been freed up

suggest change the code in the timer

It's a little late to talk about whether it's Edgar's or my routine. My samples started out being named Close(n).accdb.
Anyways, I have trampled on Edgar's, and as stated earlier, my approach is different, and I added that to Edgar's, but you may have removed it or used an older version of Edgar's .accdb. I'm not sure, and not important.

In any case, I still think my way (as explained in post #29) is valid, especially considering that you replicated the approach into form1. Your approach may be doing the same error we see below, as I don't see you tested for it. Your and my methods don't produce the variable clearing problem. So we can forget about that for now.

Here's what I'm seeing in Edgar's simple form (that I modified) compared to my semi-complex Close(n).accdb (the same problem manifests in my big app).



Why did Access start closing the form with hwnd of 22221008 and then actually close 7870338?
When did it start closing 7870338?
Notice when VBA terminates, form 22221008 is still open.

Someone here said I have to tell Access which form to close. That may be true (I don't think so, because it's optional, and if I don't specify the name, then obviously we want to close the form for which the VBA is running, not some other random form), but if it is, then how do I tell access which hwnd to close? All instances have the same form name. (As a side note, it would make my code a ton smaller if MS allowed the instancing of the form with a variable instead of a hardcoded name.)

I'd love to know, do you see anything wrong with my timer approach that would cause Access to act in the spastic manner we see above??

[CJ_London]

Quite frankly I don’t care. I cannot envisage a situation in the modern world which requires such a complicated solution. Your example of a shop assistant having more than two forms open at the same time I see as unlikely if only because they clutter up the screen.

Despite you being on my ignore list I’ve resolved the problem as presented when I took a look at your thread. I have no wish for further involvement.

you seem to revel in the idea that because something doesn’t work as you expect, it’s a bug. You seem incapable of considering other ways of achieving your objective.

so you keep on trying to walk on water whilst I’ll make use of a paddle board.

please don’t bother responding to this post, good luck with your project but you are back on my ignore list

[twgonder]

Quite frankly I don’t care. I cannot envisage a situation in the modern world which requires such a complicated solution. Your example of a shop assistant having more than two forms open at the same time I see as unlikely if only because they clutter up the screen.

Despite you being on my ignore list I’ve resolved the problem as presented when I took a look at your thread. I have no wish for further involvement.

you seem to revel in the idea that because something doesn’t work as you expect, it’s a bug. You seem incapable of considering other ways of achieving your objective.

so you keep on trying to walk on water whilst I’ll make use of a paddle board.

please don’t bother responding to this post, good luck with your project but you are back on my ignore list

You are welcome to do as you wish, but don't kid yourself.
You didn't solve the problem, and your excuses for ignoring it (and the evidence) are childish.

Your incomplete "solution" (see your first point in post #42) is no more or less complicated than mine, in fact they are quite equal if you bothered to look.
(Using set focus DoCmd.close rather than .remove, the only difference is where.)

Here's the code from MY (not Edgar's) original Close1.accdb, post#2:

    Me.SetFocus
Stop
    MsgBox "Form being forced to close: " & Me.Hwnd
Stop
    DoCmd.Close ' ObjectType:=acForm

Gee, looks kinda familiar to your solution, no? (See your comment in post#36 that I was doing it "wrong".)
Bloody hell, you can even see the code in an image in the VERY FIRST POST!
So much for your second point in post #42.
As to point #3, I'm surprised you are confusing a null string with an empty string, despite chastising me many times in the past for not reading the documentation or knowing the tool.

You didn't solve the objective, with your "paddle board" if you, again, bothered to read the posts.
How did I not consider the approach of others, when as you can see above, I tested, modified and presented the images as well as an .accdb of what I did with their ideas? (See posts# 14, 16, 17, 19, 21 23, 25, 39 and 41.)

In what world does a system administrator want to run around to dozens of computers and mad-man click on form1 to close instances of form2 rather than just click on a single button/option to secure a network app for a patch?

You've never been or had a client that has a situation as outlined in post#11? That unlikely situation, as you call it, or a variation happens to me almost every time I go to the supermarket, because... the developer of their software didn't "envisage" the real world. So, I and others wait and wait and wait or move to another queue because that developer, like you, didn't want to "clutter" the screen with one more form. But hey, maybe you live in Utopia.

So, how big is that "ignore list"? I can't imagine being a real client of yours.
I don't like getting snarky with anyone, but you and a few others just seem to think this site is your personal troll space.
Your comments are the very definition of being a troll.

I revel in the idea of forums like this where ideas/approaches can be challenged and discussed. That's my whole purpose for being here.
(Note how I challenged your whiny opinions with reference, fact, example and logic.)

You're welcome to respond. I can take it because I'm not a little man-baby that cries and takes his ball and goes home because someone doesn't accept the way he changed the rules.