Orientation of arcplan function results
arcplan function evaluation sometimes works with some "magic" to realize results as smart as possible.
The target of this article is to explain one general principle of such a smart behavior, in order to provide the application designer a better understanding about what's going on in the background and provide explanations for cases, when the behavior is not as expected (which do exist on the other hand).
Regard a table (named "myTable") which is filled with values. If you want to place a horizontal row filled with the column-wise sum below the table, you simply use the function SUM([<myTable>]) within the calculation event of the row object.
If you want to have the sum row-wise, you can use exactly the same formula for a column object, placed e.g. right to the table. Finally using it for a cell delivers the sum of all table cells.
Obviously arcplan is automatically detecting the desired orientation and content of the SUM function results.
The principle behind is: The orientation of the result of a function is depending on the orientation of the executing object.
In this example, the executing objects are the same objects which are filled with the results, so the orientation of the results is as desired.
So this behavior is adjusted to the desired use case, which works fine and intuitive in most cases.
On the other hand, there are cases in which this principle leads to a kind of unexpected behavior. This is mostly the case, if functions are not calculated by the objects themselves, but rather are assigned to them by using the assign operator ":=" or the COPY function.
In the example above, if the sum is assigned to the different objects by a button object using the copy function, like: COPY([<myTable>]; [<row>]), the row will contain the sum of all table cells in only one single value. But this is as intended, following the principle above. Here the executing object is a button, which has the same dimensionality as a cell. Therefore it delivers the same result as the cell in the described case.
For the application designer, this is kind of unexpected. So what's the solution here, if using an assignment is necessary? A workaround would be to use a row object instead of the button as executing object, entering the function at the event "On click" of the row. Now the executing object has the same dimensionality as the result object.