Use widget pools
- Last Updated: May 23, 2019
- 3 minute read
- OpenEdge
- Version 13.0
- Documentation
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 Use 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.