Q about creating OO class instances / stepping through the execution

[mdlueck]

I have been occasionally noticing while operating in Debug \ Stepped Execution mode that when execution encounters creation of a custom class object:

  Set ObjAdminPickListStandardAQEItems = New clsObjAdminPickListStandardAQEItems

That the code execution passes through both the class constructor and destructor before continuing beyond the Set statement which was creating the object. In other words I see all of this code execute:

Private Sub Class_Initialize()
On Error GoTo Err_Initialize

    Set m_PrivateCollection = New Collection

Exit_Initialize:
  Exit Sub

Err_Initialize:
  Call errorhandler_MsgBox("Class: clsObjAdminPickListStandardAQEItems, Subroutine: Initialize()")
  Resume Exit_Initialize

End Sub

Private Sub Class_Terminate()
On Error GoTo Err_Terminate

    Set m_PrivateCollection = Nothing

Exit_Terminate:
  Exit Sub

Err_Terminate:
  Call errorhandler_MsgBox("Class: clsObjAdminPickListStandardAQEItems, Subroutine: Terminate()")
  Resume Exit_Terminate

End Sub

The class appears to work properly, is able to use the m_PrivateCollection Collection object properly.

Why does the class destructor run directly following the constructor?

 

[mdlueck]

Any feedback on what I saw and posted about here...???

 

[MarkK]

One possibility is that the execution of the "New clsYourClass" creates a new instance, so Class_Initialize() runs for that instance. Then the assignment to the variable occurs, but if that variable already holds an older instance then that older instance has to be destroyed, so Class_Terminate() runs in the instance that was previously held by your variable.
Does that make sense?
So to test that you could make sure every instance timestamps itself (if you have no other way of telling instances apart) and check in the debugger which instance is initializing and which is terminating when.
Mark

 

[mdlueck]

Does that make sense?

Not really... sorry.

This would have been the first instance of this class, as I am purposely testing the new class, have break points in the class, etc... so, not possible to have another instance floating around.

I can not think of a valid explanation for the distructor to be run immediately following the constructor. I have never seen another OO language do such.

 

[Pat Hartman]

I don't want to discourage exploration and experimentation but VBA isn't an OO language although it does work with objects and classes. Rather than molding it to your image, you will be far happier (less head banging against wall) and more productive if you learn how to take advantage of the features as implemented rather than trying to impose an OO "framework" on them.

 

[mdlueck]

VBA isn't an OO language

I concede that point.

Rather than molding it to your image, you will be far happier (less head banging against wall) and more productive if you learn how to take advantage of the features as implemented rather than trying to impose an OO "framework" on them.

:banghead:

Apparently I am not allowed to know why...

I can not think of a valid explanation for the distructor to be run immediately following the constructor. I have never seen another OO language do such.

The distructor runs, which dumps from memory the Collection object (which had just gotten crated in the Constructor) and yet I am able to subsequently interact with the Colleciton object in the instance of the class which had run its distructor.

I just don't get why the distructor was called and after the distructor is called the object is able to work as expected.