previous article
arcplan is a tool which poses few limits for the developer. Due to its structure, the developer is very flexible in designing his reports. This is a major advantage, as the reports can thus be very flexibly adjusted to the users' needs. However, it may quickly turn into a disadvantage, as well, as reports may contain many hundreds of objects with correspondingly many links. Without guidelines for the development, an application quickly becomes confusing and hard to maintain. In particular, this holds true for third parties or new team members, who often find it difficult to initially adapt to an application. Even the developer himself may lose the overview.
In order to counteract this problem, we have written down a few rules below which have proved themselves in our projects. Of course, they are merely a suggestion and may be expanded at will. It is important THAT uniform rules are made at all, regardless of HOW they are designed specifically.
Color Scheme Depending on Functionalities
One of the rules which became most important for us is a color scheme depending on the functionalities of the object. For this purpose, we define the colors and their meaning on level 1.
Grouping Related Objects
Another rule is the grouping of objects. In order to design the levels more clearly, it is sensible to group related objects such as e.g. when retrieving data, and to mark them as related by another object which is placed behind them as a frame.
Dividing the Levels
It is also expedient to divide the three levels. Thus, we use e.g. the first level for the loading of the data from the data report and the compilation thereof for the view. Also, functions such as formatting the view are stored on this level.
Level 2, on the other hand, is mainly used for comprehensive functions such as printing, Excel export and favorite functions.
On the remaining level, the texts are loaded, and objects which are not currently needed, but which may be needed again later, are stored.
No Arrows across Levels
Data queries across multiple levels should be a huge no-go in every application. As the arrows are not displayed across levels, the queries are difficult to comprehend.
While connections can be made visible by turning off the arrow display, they are only displayed if the target object is marked. It is not possible to get from source objects to target objects.
Descriptions of Objects and Functions
It is important to describe/document functions with regard to arcplan applications, as well. On the one hand, this includes the description with the objects themselves, which states what the individual objects are used for, and on the other hand, the descriptions of the formulas within objects.
Descriptions regarding the entire report are also very expedient and help the developer with his work.
Functions
Theoretically, it is possible to execute functions in every object; for this purpose, various events such as “after update”, “upon click”, etc. are available. However, this frequently makes the work harder. On the one hand, the developer must know in which objects to make changes. On the other hand, synergies cannot be used this way.
Practice has shown that it is principally sensible to place functions into buttons and to merely carry out the execution of the buttons via the events in the affected objects.
If the buttons are sensibly labeled and if a little comment is attached which shows by which object the button is executed, it becomes understandable at a glance.
Updates on the View
Often, various functions must be carried out when switching menus. This includes e.g. the updating of data queries and also the execution of the formatting. The update may be collected in one object in order to avoid having to place a function behind every menu upon the switch and behind every table in case of updates. This object should be described on the first level. It is primarily important for the object that it visibly lies on the report, as it is only updated in this case.
The object is linked to the objects to be updated in the event “calculation” via the function ISEMPTY() * EMPTY() (see illustration). The formula ensures that the object is updated e.g. when a menu is switched.
Explanation: The function ISEMPTY() checks whether there is content in the stated object and returns the digit 1 or 0. This is important as the function EMPTY() times a digit always results in an empty string.
Subsequently, only an EXECUTE() command must be integrated into the “Upon Update”, so that a button is executed as described in the previous paragraph.
