Try OpenEdge Now
skip to main content
Object-oriented Programming
Programming with Class-based and Procedure Objects : Using widget pools

Using widget pools

Classes instantiated using the NEW function cannot be created in a widget pool. You can assign the object reference to each instantiated class-based object to an object reference data element.
Within a procedure file, many dynamic handle-based objects can be created using one of three memory allocation strategies. A dynamic handle-based object can be created in an unnamed widget pool, a named widget pool, or the system's unnamed widget pool. The IN WIDGET-POOL phrase of the CREATEhandle-based-object statement (for example, CREATE BROWSE or CREATE TEMP-TABLE) controls which of these three memory pools the resources for the dynamic handle-based object go into.
Within a class file, the existing rules continue to apply for how widget pools behave and from which widget pool memory is allocated for dynamic handle-based objects. Thus, you can create zero or more of the following kinds of widget pools:
*Named widget pools within the methods of a class
*Unnamed widget pools within the methods of a class
*A single unnamed widget pool scoped to the entire class
If you create a named widget pool in a method, dynamic handle-based objects will only be created in the pool if they explicitly reference that widget pool by name.
If you create unnamed widget pools within a class, the existing rules for how dynamic handle-based objects get created in an unnamed widget pool apply. These rules state that a dynamic handle-based object is created in the most locally scoped unnamed widget pool, if one has been created, and in the system unnamed widget pool, if no unnamed widget pool has been created. Unnamed widget pools created in a method are scoped to the execution lifetime of that method. Thus, unnamed widget pools created within a method can be explicitly deleted within the method using the DELETE WIDGET-POOL statement, or they are implicitly deleted by the ABL session when method execution ends.
In addition for classes, you can create two additional unnamed widget pools by specifying the USE-WIDGET-POOL option on the CLASS statement. (For more information, see Using the CLASS construct.) This creates a single, unnamed widget pool for all handle-based objects created using:
*Instance members that are scoped to the class instance. This unnamed widget pool is implicitly deleted by the ABL session when the class instance to which it is scoped is deleted.
*Static members that are scoped to the class type. This unnamed widget pool is implicitly deleted only when the ABL session in which the widget pool is created terminates.
If a class that does not specify the USE-WIDGET-POOL option inherits (either directly or indirectly) from a class that does specify the option, the subclass inherits the USE-WIDGET-POOL option, also. Furthermore, if a class does specify the USE-WIDGET-POOL option, the option applies to any classes that it is derived from when they are running as part of an instance of the class. In other words, at run time, an object has an unnamed widget pool scoped to it if any class in its hierarchy is defined with the USE-WIDGET-POOL option. As already noted, an unnamed widget pool created in one of an object’s methods takes precedence over an object's unnamed widget pool during the lifetime of the method's widget pool.