Event types

Supported

  • User-defined events can be attached to the Application object.

  • User-defined events without an ID are supported.

  • User-defined events with an ID are supported to the extent that the system message is supported.

Unsupported

  • User-defined system messages are not supported.

  • The system messages specific for the unsupported system objects/controls are unsupported.

  • Selecting the same event ID to declare two events that have different names is not supported.

  • Using the local variable AncestorReturnValue in an event of a descendant object is unsupported unless the event of the descendant object is an extended event from the ancestor object, or the AncestorReturnValue is generated in Call Super statement.

  • If a system event involves a UI operation, the subsequent event will not be triggered until the UI operation is done.

  • Avoid the following code, because it will cause system error to the deployed application:

    An event in an event sequence destroys some container (such as closing a window or destroying a user object), and then a subsequent event in the sequence calls to the container or controls/objects in the container.

    For example, in case uo_1 contains cb_1 and there is an event sequence (ue_1.ue_2.ue_3), if uo_1 is deleted in ue_2 but cb_1 is called in ue_3, application will crash.

  • In some cases, the event triggering sequence is inconsistent between PB and Appeon Mobile, for example, the code as shown below:

    event open;
    String ls_Title,ls_FilePath,ls_FileName
    Post Event pfc_PostOpen()
    is_EventTrack += This.ClassName() + '.Open1()~r~n'
    GetFileOpenName(ls_Title,ls_FilePath,ls_FileName)
    is_EventTrack += This.ClassName() + '.Open2()~r~n'
    end event
    

    In PB, the pfc_PostOpen event is triggered only after the Open event is executed completely. Whereas, in Appeon Mobile, the pfc_PostOpen event is triggered right after the GetFileOpenName function is executed.