Creates a named or unnamed widget pool in which
to contain most dynamic widgets and other handle-based objects created
during an ABL session.
Note: Does not apply to
SpeedScript programming.
Syntax
CREATE WIDGET-POOL
[ pool-name [ PERSISTENT ] ]
[ NO-ERROR ]
|
-
pool-name
- A character-string expression that specifies the name for a named
widget pool you are creating. Widget pool names are not case
sensitive.
If you omit this option, an unnamed widget pool is
created and scoped to the procedure or class-based method. That
is, a routine-scoped unnamed widget pool and its contents remain
in effect as long as the procedure or method is on the call stack, and
the pool and its contents are automatically deleted when the procedure
or method is removed from the call stack.
- PERSISTENT
- Specifies that the named widget pool is persistent. This means
that the pool and any widgets in it remain allocated after the current
procedure or method terminates. If you do not specify this option,
the pool and its contents are automatically deleted when procedure
or method execution ends.
- NO-ERROR
- Suppresses ABL errors or error messages that would otherwise
occur and diverts them to the ERROR-STATUS system handle. If an error occurs, the action of the statement
is not done and execution continues with the next statement. If
the statement fails, any persistent side-effects of the statement
are backed out. If the statement includes an expression that contains
other executable elements, like methods, the work performed by these
elements may or may not be done, depending on the order the AVM
resolves the expression elements and the occurrence of the error.
To
check for errors after a statement that uses the NO-ERROR option:
- Check the ERROR-STATUS:ERROR attribute to see if the AVM raised
the ERROR condition.
- Check if the ERROR-STATUS:NUM-MESSAGES attribute is greater than
zero to see if the AVM generated error messages. ABL handle methods
used in a block without a CATCH end block treat errors as
warnings and do not raise ERROR, do not set the ERROR-STATUS:ERROR
attribute, but do add messages to the ERROR-STATUS system handle.
Therefore, this test is the better test for code using handle methods
without CATCH end blocks. ABL handle methods used in a block with a
CATCH end block raise ERROR and add messages to the error object
generated by the AVM. In this case, the AVM does not update the
ERROR-STATUS system handle.
- Use ERROR-STATUS:GET-MESSAGE( message-num )
to retrieve a particular message, where message-num is
1 for the first message.
If the statement does not include
the NO-ERROR option, you can use a CATCH end block to handle errors
raised by the statement.
Some other important usage notes
on the NO-ERROR option:
- NO-ERROR does not suppress errors
that raise the STOP or QUIT condition.
- A CATCH statement, which introduces a CATCH end block, is analogous
to a NO-ERROR option in that it also suppresses errors, but it does so
for an entire block of code. It is different in that the error messages
are contained in a class-based error object (generated by the AVM
or explicitly thrown), as opposed to the ERROR-STATUS system handle.
Also, if errors raised in the block are not handled by a compatible
CATCH block, ON ERROR phrase, or UNDO statement, then the error
is not suppressed, but handled with the default error processing
for that block type.
- When a statement contains the NO-ERROR option and resides in
a block with a CATCH end block, the NO-ERROR option takes precedence over
the CATCH block. That is, an error raised on the statement with
the NO-ERROR option will not be handled by a compatible CATCH end block.
The error is redirected to the ERROR-STATUS system handle as normal.
- If an error object is thrown to a statement that includes the NO-ERROR
option, then the information and messages in the error object will
be used to set the ERROR-STATUS system handle. This interoperability
feature is important for those integrating code that uses the traditional
NO-ERROR technique with the newer, structured error handling that
features error objects and CATCH end blocks.
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 HANDLE NO-UNDO.
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 PROCEDURE.
|
Notes
- The
AVM automatically creates a persistent unnamed widget pool (session
widget pool) at the start of each session. Most applications
use only this session widget pool.
- In general, unnamed widget pools cannot persist beyond the scope
of the procedure or method in which they are created, except the
session widget pool, which is created by the AVM.
- If you create an unnamed widget pool in the main block of a
persistent procedure or you instantiate a class where the USE-WIDGET-POOL option
is defined somewhere in its hierarchy, the AVM creates an object-persistent
unnamed widget pool that persists for the lifetime of the
persistent procedure or class-based object, respectively. This object-persistent
widget pool then becomes the default widget pool for any internal
procedure of the persistent procedure or any method of the instantiated
class that is invoked from outside the respective persistent procedure
or instantiated class. However, any routine-scoped unnamed widget
pool created by these internal procedures or methods supersedes this
object-persistent widget pool. For more information on the USE-WIDGET-POOL
option, see the CLASS statement reference
entry.
- When you create an unnamed widget pool, it automatically becomes the
default widget pool. Each subsequent dynamically created widget
is placed in this unnamed pool unless you specifically assign it
to another pool. This unnamed pool remains the default widget pool
until it is deleted or you create another unnamed widget pool. Thus,
if you create no unnamed widget pools, all dynamically created widgets
go into the session widget pool, unless assigned to another pool.
If you create any additional unnamed widget pools, either object-persistent
or routine-scoped, the most locally scoped and recently created
unnamed widget pool becomes the default widget pool for all subsequently
created dynamic widgets.
- Persistent widget pools remain allocated until they are explicitly deleted
(with the DELETE WIDGET-POOL statement) or until the end of the
ABL 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, the AVM raises the ERROR condition.
- If a recursive procedure or method creates an unnamed widget
pool, each iteration of that procedure or method 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).
- You might want to create a new, unnamed widget pool just before invoking a new procedure
or method and then delete that pool when the procedure or method returns. This ensures
that any dynamic widgets created by that procedure or method 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.