Progress
Programming
Handbook
Named Widget Pools
Progress supports two types of named widget pools: persistent and nonpersistent. A persistent widget pool remains allocated until it is explicitly deleted or the session ends. A nonpersistent widget pool remains allocated until it is explicitly deleted or the procedure block that creates it goes out of scope. When execution of a procedure or trigger ends or goes out of scope, Progress automatically deletes any nonpersistent widget pool defined in that routine.
NOTE: A persistent procedure goes out of scope only when it is explicitly deleted. Thus, non-persistent widget pools created in it can persist as long as the procedure persists.When you create a dynamic widget, you can assign it to a named pool by using the IN WIDGET–POOL option.
The following procedure creates a named widget pool and creates a series of buttons in it:
The widget pool in this example is nonpersistent. Therefore, if you omit the DELETE WIDGET–POOL statement at the end of the procedure, the widget pool is automatically deleted when the procedure ends.
Because all the widgets in
p-dybut2.p
are created in the main procedure and are deleted at the end of the procedure, the widget pool does not need to be persistent. However, the following procedure requires a persistent widget pool. The following procedure,p-dybut3.p
, accepts a month and year and then creates a button for each order entered during that month:
In this example, the widget pool is created within the internal procedure make–buttons. Because the buttons must be available outside the internal procedure, the widget pool must be persistent; otherwise the pool would be deleted at the end of the internal procedure. When you change the month or year value, the GO trigger deletes the widget pool (and therefore deletes all the buttons as well). It then runs make–buttons to create a new widget pool and a new set of buttons.
Note that the internal procedure, disp-order, creates a window in the persistent widget pool. When you change the month or year, any windows so created are deleted along with the buttons.
When you use a persistent widget pool you must make sure the pool is deleted. In
p-dybut3.p
the DO group surrounding the WAIT–FOR statement ensures that control will pass to the DELETE WIDGET–POOL statement no matter how you exit the procedure.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |