|
Main Index
PREV
NEXT
|
Within IDF select Editors on the pulldown menu, then Templates followed by Component. The Define Component (Template) window should open up, as hown in Figure 1.
Figure 1 - Define Component (Template) window
Press the New button to add a new template. Note here that I use a prefix of 'CT_' on all my Component Templates so that I am easily able to separate them from other component types. In this way I can export all of my templates in a single operation.
The properties that are available on this screen are the standard properties that are available to all components. Any settings you establish here will be automatically inherited by any components created from this template. Any subsequent changes to these settings will also be inherited by any components when they are next compiled, except for any settings which have been overridden.
Press the Structure button and you will be taken to the familiar Component Editor with its Paint Tableau, Status Box, Tool Palette and Structure Window. Here you can define the entities and fields for the component template. When you add an entity to a component it is initially given a default name of ENTITY_1, ENTITY_2, etc. You should then right-click and select Rename to bring up the Rename Entity window as shown in Figure 2.
Figure 2 - Rename Entity window
By default the model name is set to UGENERIC, the 'Generic' checkbox in the bottom left hand corner is set ON and the list of entity names is empty. Use this screen to define a more meaningful name to your generic entity instead of the default. A list of various entity names that I use is given in the Introduction.
If you unset the 'Generic' checkbox then the entity will not be generic. You will be invited to first select an application model, then one of the entities within that model. This will then become a physical entity and will not require any action in the Object Binding screen
Proc code can be defined in any form, entity or field trigger as normal.
When a component is first constructed from a template all of the trigger code within the template will be copied to the new component. However, should any changes be subsequently made to any trigger code in the template only those changes to form-level triggers will be incorporated into the component when it is next compiled. This is known as template inheritance and remains effective all the while no changes are made to the inherited code within the component.
If the proc code within any inherited trigger is modified in any way then the code in that trigger becomes a local variation and all inheritance with the proc code in the template for that trigger is lost. It is possible to re-establish inheritance from the template, but than any local changes will be lost.
If the component template requires any local procs it is tempting to put them in the standard <Local Proc Modules> trigger. However, if the developer wishes to create additional local procs in the same trigger this will make the entire trigger a local variation and all inheritance between the code in that trigger and the code in the template will be lost. For this reason if a component template contains any local proc modules I prefer to place them in a different trigger where they will be out of the way and unlikely to lose their inheritance.
In the absence of an <Inherited proc Modules> trigger I tend to place my local proc modules in the trigger where they are most likely to be referenced. For example:-
Within proc code it is possible to include a reference to a generic entity by enclosing the generic name in a set of '<' and '>' signs, as in the following:-
clear/e "<MAIN>" getlistitems/occ $params$, "<MAIN>" retrieve/x "<MAIN>" if (!$dbocc(<MAIN>)) putmess "primary key: %%$params$" message $text(M_90007) ; no entry found exit(1) endif
Within proc code it is possible to include a reference to a generic field by enclosing both the generic field and entity names in sets of '<' and '>' signs, as in the following:-
$prompt = <FIRST_FIELD.<MAIN>>
In the above examples I have shown the generic entity and field names in upper case, but in reality it does not matter whether they are upper or lower case.
 |
http://www.tonymarston.net |