Progress
Programming
Handbook


Unnamed Widget Pools

Any unnamed widget pool you create becomes the default pool until it is deleted or until you create another unnamed widget pool. Any unnamed pools you create are scoped to the routine in which they are created. Also, any subprocedure or trigger inherits, as its default pool, the most recent unnamed widget pool created in a calling procedure until (and unless) it creates an unnamed widget pool of its own. When execution of a routine ends, or it goes out of scope, any unnamed pools created in the routine (and therefore, all widgets in them) are automatically deleted.

NOTE: A persistent procedure goes out of scope only when it is explicitly deleted. Thus, unnamed widget pools created in it can persist as long as the procedure persists.

If you omit the IN WIDGET–POOL option in the statement that creates the widget, the widget is automatically assigned to the most recently created unnamed widget pool that has not been deleted.

You can delete the current default widget pool by using the DELETE WIDGET–POOL statement without a pool name. You can delete the default widget pool only within the routine that defined it. For example, if you define an unnamed widget pool in a procedure, you cannot delete it in a subprocedure or trigger called by that procedure. If you attempt to do so, Progress ignores the DELETE WIDGET–POOL statement.

You cannot specify the PERSISTENT option when you create an unnamed widget pool. All unnamed pools, except the session pool and pools created in persistent procedures, are nonpersistent.

You might use an unnamed widget pool, for example, to ensure that all widgets created in the default pool in a run procedure are deleted when that procedure returns or goes out of scope. For example, the following procedure calls p-dybuts.p (see "Widgets and Handles"):

p-unname.p
CREATE WIDGET-POOL.
RUN p-dybuts.p.
DELETE WIDGET-POOL. 

In this example, the CREATE WIDGET–POOL statement creates a new default widget pool. Any widgets created in the default pool within p-dybuts.p are placed in this pool. After p-dybuts.p completes, the DELETE WIDGET–POOL statement deletes that widget pool.

On the other hand, in a persistent procedure, you can use an unnamed widget pool to ensure that its dynamic widgets are not deleted after it returns from instantiating its persistent context. Otherwise, if the calling procedure deletes the widget pool that was current when it created the persistent procedure, any dynamic widgets created for the persistent context are deleted as well.

Thus, if you ran p-dybuts.p persistently in p-unname.p, creating an unnamed widget pool in p-dybuts.p prevents p-unname.p from deleting the dynamic widgets created in the persistent context of p-dybuts.p. For a working example, see the section on multiple-window applications with persistent procedures in Windows."


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095