Product
Support
Everything Else
When is an abacus calculation unavailable to a Use ◊ From ◊ tile?
Note: this technote documents an ‘ad hoc’ discovery that is thought to be useful in answering a longstanding question. If you find the information presented here to be incorrect or incomplete — please let us know.
Introduction

It has been observed that some calculations fail — that is, return undefined in all cases — unless a specific abacus used in the calculation is present on the view. This technote defines the situations when this is required, why it is so, and offers two ways to work around this limitation.

What is a Record?

Calculations are made based on the records found in a relation. A record is comprised of the fields in the relation, along with the abaci (calculations) in that relation. Basically, when you are viewing a record, Helix has access to every abacus in that relation, so those abaci can be used as display elements, conditional triggers, subform links, and more, as well as in subsequent calculations.

However, there is at least one class of abacus that falls outside this basic interpretation, as explained below.

The Use/From Tile

The Use ◊ From ◊ tile is used to ‘pull’ a value from the currently displayed record to another relation (or to another record within the same relation) for subsequent calculations.

One place where this is useful is in restricting a subform (or dynamic popup menu) based on data from the current record. For example, a subform that displays data for the same month as the currently displayed record would require a Use field:'date' From relation:'x' tile to bring the date to the relation where the related data resides, so that the month can be extracted, the matching records found and displayed in the subform (or dynamic popup).

This example works because the field ‘date’ is an integral part of the target relation. Likewise, any direct calculation based on that field would also be accessible. For example, abaci calculating the ‘first of the month’ and ‘last of the month’ may already exist in this relation, and it would be perfectly logical to Use abacus:'FirstOfMonth' From relation:'x' to get the beginning of the month instead of retrieving the actual date and building another ‘first of the month’ abacus in the secondary relation.

Where It Fails: One Example

However, if the abacus’ calculated value requires access to another relation, via a Lookup ◊ For ◊ = ◊ In ◊ tile, the calculation will fail, as the data being looked up is indirect data that is not actually part of the displayed record.

For example: consider a scheduling program that has predefined ‘events’ that occur at specific times. This application would contain an ‘Event Types’ relation, containing data that includes: { Event Type, Day Of Week } and an ‘Events’ relation, where individual events are scheduled contains data that includes: { Event, Date }. A third relation, containing ‘Days’ (the numbers 1–31) is used to fabricate dates for the month of the event being currently entered. When an event is being entered, the user enters the Event Type and a dynamic popup menu attached to the Date field shows only dates that fall on the day of the week for which this event type occurs. The image on the right illustrates this concept.

The problem is that, because this record does not contain the ‘Day of Week’ for this event, it has to acquire that data via an abacus containing a Lookup field:'Day of Week' for field:'Event Type' = field:'Event' in relation:'Event Types' tile. This value is pulled to the ‘Days’ relation by an abacus containing a Use abacus:'LkupDOW' from relation:'Events' tile.

In this situation, the abacus that looks up the day of the week is an indirect calculation, and as a result, it always returns ‘undefined’ to the Use ◊ From ◊ tile in ‘Days’ and so any subsequent calculations will fail to return the desired result, which in this case are upcoming dates for the day of the week of our weekly event.

Two Solutions

There are two ways to work around this limitation:

  1. Place the abacus containing the lookup ◊ on the template. This causes Helix to place that calculated value into its internal data table for the record, giving the Use abacus:'LkupDOW' from relation:'Events' tile a value to retrieve. This rectangle can have its ‘visibility’ properties turned off if you do not want its data displayed on the view.
  2. Instead of ‘using’ the looked up value, use a direct value that enables you to perform the lookups in the secondary relation. In our example above, a Use field:'Event' From relation:'Events' abacus pulls the direct value (event type) to the ‘Days’ relation, from which the Lookup ◊ operations can be done successfully.
Sample Collection

A sample collection (Helix 6.0 or higher required) showing all three (two working, one failing) techniques is available via this link to our Collection Examples library.

Conclusion

This technote details one situation where the absence of an abacus on a view results in that calculation being unavailable for abaci that reference them. There may be other similar situations, which will be documented as they are discovered.