| 
       DELETE WIDGET-POOL  pool-name  NO-ERROR 
       | 
 Check the ERROR-STATUS:ERROR attribute to see if the AVM raised the ERROR condition.
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.
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.
Use ERROR-STATUS:GET-MESSAGE( message-num ) to retrieve a particular message, where message-num is 1 for the first message.
   NO-ERROR does not suppress errors that raise the STOP or QUIT condition.
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.
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.
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.
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.
  | 
       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 MOVABLE = 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. WAIT-FOR CHOOSE OF b_quit IN FRAME butt-frame. PROCEDURE dispmsg: MESSAGE "You chose button " SELF:LABEL. END PROCEDURE. | 
 When you delete a widget pool, all widgets in that pool are automatically deleted.
When you delete a widget pool, all widgets in that pool are automatically deleted.
   If you do not delete a non-persistent widget pool, it is deleted when the procedure or method that created it ends. If you do not delete a persistent widget pool, it is deleted when the session ends.
If you do not delete a non-persistent widget pool, it is deleted when the procedure or method that created it ends. If you do not delete a persistent widget pool, it is deleted when the session ends.
   All named widget pools are globally scoped. While a named widget pool is allocated, any procedure or method within the same process can access that widget pool. If you try to delete a named widget pool that does not exist, the AVM raises the ERROR condition.
All named widget pools are globally scoped. While a named widget pool is allocated, any procedure or method within the same process can access that widget pool. If you try to delete a named widget pool that does not exist, the AVM raises the ERROR condition.