Dependencies Between Conceptual ESI Sources and Data in ESI Tables

Two sources of end user interface look and feel are the:

·	Conceptual specifications which you have made in the Definer and which are stored in the conceptual repository.

·	GUI specifications you have made in the Windows Designer and which are stored in ESI tables.

To understand how changes to one source affect the result of the other, you need to keep in mind the following rules:

·	All changes made to the conceptual repository are automatically synchronized to the GUI window classes and thereby to the eventual runtime interface.

·	Specifications in ESI tables automatically override (GUI effects of) conceptual specifications.

Example 1

You have added a new column to a table. A new default control for this column (often a text box) will be added automatically to ALL window classes based on the table, including window classes you have already customized ("painted") in the Windows Designer, and any subclasses you may have created.

If you had already finely tuned the layout or behavior of one or more of these classes or subclasses, this "painted" result may no longer look acceptable. Redesigning the window is then necessary; you cannot disable automatic re-synchronization of conceptual changes.

Example 2

You decide that a certain column control should not appear on a certain info window, but you still want it on all other window classes based on the table.

Delete the column control from the info window class. This results in Delete information being stored in ESI tables. Independently of conceptual changes to the table, the column control will now no longer appear on this info window or any of its subclasses, because the Delete information overrides conceptual information.