Release 10.1A: OpenEdge Development:
Progress 4GL Reference

> ## CREATE WIDGET-POOL statement

> Creates a named or unnamed widget pool.

> Note: Does not apply to SpeedScript programming.

> #### Syntax

>     CREATE WIDGET-POOL
>       [ pool-name [ PERSISTENT ] ]
>       [ NO-ERROR ]

> ``pool-name``

> A character-string expression specifying the name of the pool you are creating. If you omit this option, an unnamed pool is created. Widget pool names are not case sensitive.

> `PERSISTENT`

> Specifies that the pool is persistent. This means that the pool and any widgets in it remain allocated after the current procedure terminates. If you do not specify this option, the pool and its contents are automatically deleted when procedure execution ends.

> `NO-ERROR`

> Suppresses error messages if the specified widget pool already exists. You can then test for the ERROR condition to verify that the widget pool does, in fact, exist.

> Example

> The following example lets you create a series of dynamic buttons. All the buttons are created within a named widget pool. Because the widget pool is created within a trigger, it is defined as persistent so that it remains allocated after the trigger ends. You can at any time choose to delete the entire widget pool and start over.

> r-widpl.p
>     DEFINE VARIABLE wh AS WIDGET-HANDLE.

>     DEFINE BUTTON b_create LABEL "Create Button".
>     DEFINE BUTTON b_del    LABEL "Delete Buttons".
>     DEFINE BUTTON b_quit LABEL "Quit"
>       TRIGGERS:
>         ON CHOOSE
>         DO:
>           IF VALID-HANDLE(wh) THEN
>             DELETE WIDGET-POOL "new-buttons".
>           QUIT.
>         END.
>       END.

>     DEFINE FRAME butt-frame
>       b_create b_del b_quit
>       WITH ROW SCREEN-LINES - 2.

>     DEFINE FRAME new-buttons
>       WITH SIZE 76 BY 11 CENTERED ROW 2 TITLE "New Buttons".

>     ON CHOOSE OF b_create IN FRAME butt-frame
>     DO:
>       STATUS INPUT "Press RETURN to select a new button".
>       IF wh = ? OR NOT VALID-HANDLE(wh) THEN
>         CREATE WIDGET-POOL "new-buttons" PERSISTENT.
>         CREATE BUTTON wh IN WIDGET-POOL "new-buttons"
>         ASSIGN FRAME = FRAME new-buttons:HANDLE
>           ROW = RANDOM(2, 9)
>           COLUMN = RANDOM(2, 58)
>           LABEL = "BUTTON " + STRING(etime)
>           SENSITIVE = TRUE
>           VISIBLE = TRUE
>           TRIGGERS:
>             ON CHOOSE PERSISTENT RUN dispmsg.
>           END.
>     END.
>     ON CHOOSE OF b_del IN FRAME butt-frame
>     DO:
>       IF VALID-HANDLE(wh) THEN
>         DELETE WIDGET-POOL "new-buttons".
>       STATUS INPUT.
>     END.
>     ENABLE b_create b_del b_quit WITH FRAME butt-frame.

>     DO ON ENDKEY UNDO, LEAVE:
>        WAIT-FOR CHOOSE OF b_quit IN FRAME butt-frame.
>     END.

>     IF VALID-HANDLE(wh)
>     THEN DELETE WIDGET-POOL "new-buttons".

>     PROCEDURE dispmsg:
>       MESSAGE "You chose button " SELF:LABEL.
>     END.

> #### Notes

> - Progress automatically creates a persistent unnamed widget pool at the start of each session. Most applications use only the session widget pool.

> - Unnamed widget pools cannot be persistent, except the session widget pool, which is created by Progress.

> - Persistent widget pools remain allocated until they are explicitly deleted (with the DELETE WIDGET-POOL statement) or until the end of the OpenEdge session that created them.

> - All named widget pools are globally scoped. While a named widget pool is allocated, any procedure within the same process can access that widget pool. The name of a widget pool must be unique among all widget pools for the process. If you try to create a widget pool with the same name as an existing pool, Progress raises the ERROR condition.

> - If a recursive procedure creates an unnamed widget pool, each iteration of that procedure creates a separate pool. If a recursive routine creates a named widget pool, you must ensure that only one iteration creates the pool (where all iterations can share it) or use a different name in each iteration (where each creates and uses its own pool).

> - When you create an unnamed widget pool, it automatically becomes the default widget pool. This means that each subsequent dynamically created widget is placed in that pool unless you specifically assign it to another pool. The unnamed pool you create remains the default widget pool until it is deleted or you create another unnamed widget pool.

> - You might want to create a new, unnamed widget pool just before invoking a new procedure and then delete that pool when the procedure returns. This ensures that any dynamic widgets created by that procedure in the default pool are deleted immediately. For example:

>     CREATE WIDGET-POOL.
>     RUN xyz.p.
>     DELETE WIDGET-POOL.

> Similarly, you might want to store all dynamic widgets for a subsystem within a specific named pool. For example:

>     CREATE WIDGET-POOL "oe-pool".
>     RUN ord-ent.p
>     DELETE WIDGET-POOL "oe-pool".

> In this example, the procedure ord-ent.p must reference the oe-pool for each dynamic widget it creates.

> #### See also

> CREATE widget statement, DELETE WIDGET-POOL statement

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