Try OpenEdge Now
skip to main content
GUI for .NET Programming
Accessing and Managing .NET Classes from ABL : Referencing and instantiating .NET classes : Instantiating and managing .NET class instances : .NET class instances and garbage collection
 
.NET class instances and garbage collection
.NET handles garbage collection for any .NET objects involved in an ABL session. However, if you assign a .NET object reference to an ABL object reference variable (or other data element), this works like any native .NET reference to prevent .NET from garbage collecting the object. Once the ABL object reference no longer exists and no other .NET reference to the object exists, the object is again available for .NET garbage collection.
ABL references to .NET class instances require both ABL and .NET garbage collection. For pure .NET classes, the garbage collection is all in the .NET context because the ABL context maintains only an object reference to the .NET class. However, for ABL-derived .NET classes, the ABL context also maintains its own class instance, possibly including a destructor. Therefore, garbage collection is more complicated and can be much more significant because the ABL instance is not garbage collected in the ABL context until there are no more ABL references to it and the .NET context completes its own garbage collection for the class. For more information on ABL-derived .NET classes, see Defining ABL-extended .NET objects.
Caution: When a .NET modal form (dialog box) is open, it can be closed in a way that prevents automatic garbage collection on the form object. Thus, after a .NET dialog box is closed and no longer needed by your application, you must call the Dispose( ) method on the form object to ensure that both the form and the .NET controls that it contains are garbage collected. For more information, see Blocking on modal dialog boxes.
Avoid using the DELETE OBJECT statement to explicitly delete the ABL component of an ABL-derived .NET object unless you are sure that there are no more references to this object within the .NET context. It is possible for the .NET context to have an active object reference to the ABL component of the object after no more ABL object references to the object exist. Prematurely deleting the ABL component of such an object can cause unpredictable behavior in the .NET context.
Note that in certain cases, ABL resources can be held by .NET and prevented from being removed from the ABL context. This can happen, for example, when a Progress.Data.BindingSource (ProBindingSource) object that was attached to a ProDataSet is awaiting .NET garbage collection. Until it is garbage collected, all internal buffers and queries for the ProDataSet remain in the ABL context.
You can force immediate removal of these excess buffers and queries by doing one of the following:
*Calling the .NET Dispose( ) method on the ProBindingSource object reference (if still available
*Explicitly deleting the ProBindingSource object using a DELETE OBJECT statement
*Deleting the ProDataSet for which the buffers and queries were created.
However, before deleting such ABL resources, be certain that .NET is no longer using them. For more information on ProBindingSource objects, see Binding ABL Data to .NET Controls.