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.
