Messages from the server to the client are divided into information messages and warnings. The information messages will just show a message in the client in difference to warning messages, where the end user will get the opportunity to continue or interrupt the current transaction. The message text should be translatable and must therefore be prefixed with a ordinary message key (see examples). Read more about syntax of messages in section Make Messages Translatable.
The warnings will only appear in forms that have warnings enabled at the design time through F1 Properties. The default setting is that warnings are enabled in form windows and disabled for table windows.
Note: Enabling warnings for table windows will noticeably decrease the performance of that window when saving.
Specification of Interface¶
The methods for handle Client Information messages are found in package Client_SYS and the interfaces are described below. The p1_ through p3_ arguments are for optional variables in the message.
|Clear_Info||Clears all stacked information and warning messages|
|Add_Info||Adds an information message to the stack|
|Add_Warning||Adds a warning message to the stack|
|Get_All_Info||Fetches all stacked information and warning messages|
Usage of Client Information¶
The framework generally handles the client presentation of the information/warning messages automatically. Standard transaction methods
Remove__ uses the variable info_ to transfer the messages up the client. The client framework decodes the information stored in the same variable. During a transaction the server methods are called twice from the client (if warnings are enabled for current data source, see the F1 Properties dialog). The only difference between the calls is the value in the parameter action_. In the first call, action_ is set to CHECK. This results in only the validation part of the server method (e.g.
Check_Common___) is executed and where warning messages can be added. Warning messages will be formatted and presented, one at a time, and users are able to answer OK or Cancel. If they answer Cancel, the transaction breaks. Otherwise, if the answer is OK, the transaction will continue by accessing the same server method once again. The only difference now will be that the action_ will be set to DO. The validation part (e.g.
Check_Common___) will be executed one more time and then the rest of the code (e.g.
The example below shows how to use this functionality in the