VB6 circular references: explicit Cleanup method or ObjPtr weak back-reference?

Question

Classic Visual Basic 6 (pre-.NET) and VBA destroy a COM object only when its reference count reaches zero. A parent class and child class that hold references to each other therefore never terminate: Class_Terminate never fires, and any cleanup code placed there silently never runs.

Two documented ways to break such a cycle exist:

Explicit teardown — a Cleanup method that sets the child's back-reference to Nothing; type-safe, but every call site must remember to invoke it.
Weak back-reference — store the parent as an ObjPtr value (an undocumented VB6 internal) or a keyed lookup; structurally leak-free, but dereferencing a parent that already died risks a crash.

The constraint: in a long-lived VB6 codebase, third-party call sites cannot all be audited, yet cleanup must still run. Teardown order — who nulls whose reference first — is left to the developer.

Which approach holds up better when callers outside the team may never invoke Cleanup?
Given that ObjPtr is undocumented, is it stable enough to rely on across VB6 runtime builds, or should it be treated as a last resort?
Does the direction in which the cycle is broken (parent clears the child, or child clears the parent) affect whether Class_Terminate eventually fires?

Tasadduq Burney · Answer

The Direct Resolution
When third-party callers cannot be trusted to invoke a manual Cleanup method, the weak back-reference (ObjPtr) approach is the only way to ensure objects are destroyed without external intervention. Because VB6 relies on strict COM reference counting, an explicit teardown method is a policy, not a mechanism; if it is not called, the memory leaks. Using ObjPtr prevents the reference cycle from ever forming, allowing Class_Terminate to fire as soon as the primary external reference is released.

Analysis of Implementation Strategies
ObjPtr Stability and Risks
While ObjPtr is undocumented, it has remained stable across VB6 runtime builds because it simply retrieves the raw memory address of the COM object. However, it is a "dangerous" tool because it bypasses the reference counter. If the parent object is destroyed while the child still attempts to use the ObjPtr, the application will likely crash or throw an Object variable or With block variable not set error.

The Direction of the Break
In a circular reference, the cycle is a closed loop. Breaking the link in either direction (Parent $\rightarrow$ Child or Child $\rightarrow$ Parent) is sufficient to allow the reference count to drop toward zero. It does not matter which side is nulled, provided that no other external references to those objects exist.

Implementation Steps for Weak References

Store the Pointer: In the Child class, instead of an object variable for the Parent, store the parent's address as a Long using ObjPtr(ParentObject).
Restore the Object: When the Child needs to access the Parent, use a helper function or a Set operation to cast the Long back into an object reference temporarily.
Verify Termination: Add a Debug.Print "Terminated" statement to the Class_Terminate event of both classes to confirm they are being released.

Verification Example
' In Child Class
Private m_ParentPtr As Long

Public Property Set Parent(ByVal pParent As ParentClass)
    m_ParentPtr = ObjPtr(pParent)
End Property

Private Function GetParent() As ParentClass
    ' Warning: This assumes the parent still exists in memory
    Set GetParent = ObjectFromPointer(m_ParentPtr)
End Function

Note: ObjectFromPointer is a common API-based wrapper used in VB6 to convert a Long back to an object.

Missing Diagnostic Detail
To refine this recommendation: Are the Child objects owned exclusively by the Parent, or can they outlive the Parent? If Children can outlive the Parent, the ObjPtr approach requires a validation check to prevent crashes upon dereferencing.

VB6 circular references: explicit Cleanup method or ObjPtr weak back-reference?

1 answer

The Direct Resolution

Analysis of Implementation Strategies

ObjPtr Stability and Risks

The Direction of the Break

Implementation Steps for Weak References

Verification Example

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments