The Problem

Every time you create a new form, UNIFACE defaults code into certain triggers, for example, the erase trigger has the erase statement. In version Six, if you want to remove this code, you have to remember to do this. In UNIFACE Seven, you can use templates to help you create your forms. However, this introduces a different set of issues. Wouldn’t it be useful if you could change the default code UNIFACE uses?

The Solution

It is possible to change the default proc code used in application, component and entity-level UNIFACE triggers in versions 6 and 7 (not at menu-level). UNIFACE uses messages for the source code of these triggers. In the development environment, when UNIFACE looks for a message, it will check first in the library specified in the assignment file, and if it cannot be found there, it will look in the default library.

If you create you own library and create your own variation of these messages within this library, all you have to do is specify this library in your assignment file as follows:

$variation = DBS_LIB

where DBS_LIB is your new library.

When you create a new form, UNIFACE will populate the triggers with the code specified in the message definitions for DBS_LIB. However, you need to know the names of the messages containing the default code for the UNIFACE triggers in the default (USYS) library so that you can define them in your own library. These names are listed for each of the triggers in Chapter 4 of the Proc Language Reference Manual.

Example 1

If you want to change the default code so that, when creating a new occurrence, a check is done to ensure that the user has access rights to insert records, you could write your own default code for the <CREOCC> trigger as follows:

; trigger: <Add/insert Occurrence>
$$ENTNAME = $entname
call GP_SECURITY
if ($status >= 0)

if ($rettype = 65)

creocc "INVOICE", $curocc + 1 ;add occurrence

else

creocc "INVOICE", $curocc - 1 ;insert occurrence

endif

else

message "You do not have privilege to add records"
return (-1)

endif

Example 2

If you want perform a <STORE> whenever the user does an <ACCEPT>, you first need to create a new library called NEW_LIB. Once this is done, create a message called ACCEPTDEF. This is the same name as the message containing the default UNIFACE proc code in the USYS library. Specify a language. In the ‘Details’ edit box, type in your new code to perform the store:

store

if ($status <0)

message $text(1500)
rollback

else

if ($status = 1)

message $text(1723)

else

commit
if ($status < 0)

rollback

else

message $text(1805)

endif

endif

endif

Once this is done, check that the following line exists in your assignment file:

$variation = NEW_LIB

If it does not, you will have to add it and rerun the IDF to ensure that UNIFACE is pointing at the correct library. Now create a new form. Your new code should be in the <ACCEPT> trigger of the form. If it is not, the problem will be caused by your .dol file.

DOL Files

When you create a new message, it is compiled in the UOBJ.TEXT table. If you have one of the following definitions in your assignment file the idf will look first in the .dol file for the message:

$SEARCH_OBJECT = FILE_ONLY
$SEARCH_OBJECT = FILE_FIRST

If you do not update your dynamic object library (.dol) file, the new message definition will not exist in the .dol file and the default code (there is none) will be displayed in the <ACCEPT> trigger of the new form/s you create. Therefore, if you are using a .dol file to access your global definitions, you must remember to update it after creating new messages in order to be able to use these new messages. If your assignment file contains one of the following assignments it is not necessary to update the .dol file because the message definitions are accessed directly from UOBJ.TEXT:

$SEARCH_OBJECT = DBMS_ONLY
$SEARCH_OBJECT = DBMS_FIRST

Limitations

Overriding the default UNIFACE proc code in this way can only be done when creating new forms. These new definitions are not inherited by existing forms. Vice versa, once you have created a new form with your own message definitions, you cannot restore the default UNIFACE proc code to the same form at a later stage unless you do it manually. Therefore, it is worth spending some time on deciding which triggers to override and what code will be used in these triggers before starting.

Copyright ©2000 OCS Consulting plc