Class_Terminate() on project reset? (4 Viewers)

[riktek]

I'm mostly seeking to confirm my understanding but the question is whether Class_Terminate() runs on or immediately after a project reset.

I don't think so.

Some sources (including LLMs) state otherwise, however, equating a reset with clearing the sole variable containing an instance of a class and stating affirmatively that the event procedure will, or should, run.

What I observe, however, is that, while resets that I trigger unquestionably clear variables containing pointers to class instances, this does not invoke code in the event procedure. I can trigger that code only by clearing the variable or assigning a new class instance to it, which of course displaces the prior object.

I'm curious others' thoughts on the topic, and thanks for any input.

 

[arnelgp]

when runtime error occors, variables are destroyed.

 

[KitaYama]

when runtime error occors, variables are destroyed.

Only in accdb. Not in accde. (Not sure, only per my immature experience)

 

[sonic8]

I'm mostly seeking to confirm my understanding but the question is whether Class_Terminate() runs on or immediately after a project reset.

I don't think so.

You are correct.
The Reset ("Stop" icon) button in the VBE toolbar, the "End" button in the debug dialog, and the End statement in VBA code immediately terminate/reset the running project without running any further code in Class_Terminate event procedures.
[Edit]
The code in or Form_Unload/_Close event procedures will still run though.
[/Edit]

 

[sonic8]

Only in accdb. Not in accde. (Not sure, only per my immature experience)

It depends on whether the runtime error is handled or not. The behavior is basically the same with an accdb and accde file, but with an accdb you do have the choice to debug the code, which will prevent variables from being reset.

 

[RonPaii]

Easy to test.

Class1

Private Sub Class_Initialize()
    Debug.Print "Class_Initialize"
End Sub

Private Sub Class_Terminate()
    Debug.Print "Class_Terminate"
End Sub

Module1

Public Sub Test()
    With New Class1
        Debug.Print "Module1 Test"
    End With
End Sub

Normal run

test
Class_Initialize
Module1 Test
Class_Terminate

Run with reset on break point on "Module1 Test"

test
Class_Initialize

 

[KitaYama]

It depends on whether the runtime error is handled or not. The behavior is basically the same with an accdb and accde file, but with an accdb you do have the choice to debug the code, which will prevent variables from being reset.

I have a public variable that holds the ribbon object.
I also have a function without error handling.
When testing in accdb and call the function, the public variable is destroyed and later, invalidating the ribbon causes an error, because the variable is empty.
When I create an accde and go through the same steps, invalidating the ribbon doesn't fail. That's why I assume in accde unhandled errors don't destroy public variables.
I'll test again when I'm back to my pc.

 

[riktek]

when runtime error occors, variables are destroyed.

Yes, of course, but the question really is, then, what? Destroying a variable containing a class instance will destroy the instance. So far, so good but do this manually and Class_Terminate() executes, do it with a reset and it doesn't.

The consensus seems to be that a reset (or an End statement) preempts the event.

 

[KitaYama]

It depends on whether the runtime error is handled or not. The behavior is basically the same with an accdb and accde file, but with an accdb you do have the choice to debug the code, which will prevent variables from being reset.

Access – TempVars | DEVelopers HUT

Everything you've ever wanted to know about Access TempVars (Temporary Variables). How to create, retrieve and delete TempVars in either VBA or through Macros.

www.devhut.net

From above link:

I should also point out that the above statement is true of uncompiled versions (mdb, accdb, …). Compiled versions (mde, accde, …) do not re-set local, or even global variables because of un-handled errors.

 

[cheekybuddha]

The consensus seems to be that a reset (or an End statement) preempts the event.

I think the consensus is that you should handle your errors