Everything Else
Changes to the use of custom data formats

Helix RADE provides the ability to format the display of data in a collection. Formats can be defined at the field (or abacus) level, and custom formats can be applied at the template rectangle level.

This technote discusses the interaction between these format options, and which options are preferred (and which uses should be avoided).

Field (and Abacus) -Level Formatting

When a field is defined, the collection designer can specify the default format for displaying the data stored in that field. Each data type has its own set of formatting options — the image on the right showing the options for date data.

The focus of this technote is on the Custom control property (the last one shown in this example) and how settings made at the field (or abacus) level interact with settings made at the template level.

It is important to note — when formatting at the field level — that this is the default format for that field. It is always possible to override this format with a Custom control format in any rectangle where the field is used.

Although the full compliment of display options exist at both the field and rectangle levels, certain options are more logically applied at one level or the other. For example, it is perfectly reasonable to set the number of decimal places displayed for a number or fixed point field at the field level, it does not really make sense to set a flag field to always display as a checkbox. In fact, setting such a control can actually hinder the ability to work with your data.

Our position that it is proper to set any format property except the custom control at the field level, and that custom controls should only be set at the template rectangle level. The full reasons behind this recommendation are beyond the scope of this technote, but it should be noted that we are considering removing the ability to set custom control formatting at the field level in a future version of Helix.

Classic Bugs and Quirks

There are a number of bugs and quirks in the way custom display formatting is handled in Classic Helix RADE. Consequently, you may find that when transitioning to Helix RADE 6.2 (and later) some data may not display as expected, due to bugs that existed in prior versions of Helix.

For example: when a field is added to a rectangle in Classic RADE, the custom formatting from the field is copied in to the rectangle, resulting in two copies of the same formatting information being stored within the collection structure. Because of the duplication of data, Classic Helix would, in certain situations, use the wrong formatting data, resulting in a view that was not as intended. A good example is a quick entry view: if you define a custom format for a field, add a quick entry view, and then change the field’s custom format, the quick entry view does not see the change. Other cases where changes to the field format are not reflected on templates have also been observed. (In all these cases, it was always possible to work around the bug by ‘fiddling’ with the icons.

Another issue in Classic Helix RADE is that, when a custom format is removed from a field (or abacus or template) the custom formatting data is supposed to be completely cleared from the collection. This means that, should you subsequently decide to re-establish the custom format, it must be reconstructed in its entirety. It also means that when bugs prevented that clearing (as in the quick entry view example above) the internal state of the fields, abaci and rectangles can be confused, requiring the aforementioned ‘fiddling’ to reset them properly.

Changes in Helix 6.2

Helix RADE 6.2 brings a number of changes to the way custom control formatting is handled at the rectangle level. The most important change is that formatting a Custom control is not enough. You must also be sure to turn the Use custom display property on, or the custom format will be ignored and the default format (from the field) will be displayed.

Beginning in 6.2.1, the Use custom display property is automatically turned on whenever a change is made in the rectangle’s data display properties.

The second change to note is that the Use custom display property is now wholly independent of the Custom control property. Unlike the ‘Icon/Custom’ property in Classic RADE, turning ‘Use custom display’ off does not delete the custom format from the rectangle. The custom control is deactivated but the custom control settings are retained. Should you decide to subsequently reactivate them, all that is necessary is to turn Use custom display back on.

However, this leaves open the problem of disposing of obsolete structure. If an icon is used in a custom control format (only possible in the case of dynamic popup menus) and then the custom control is deactivated, the icon is still considered ‘in use’ by that rectangle. Should you want to delete that icon, it is now necessary to temporarily reactivate the Use custom display property and change the Custom control property to ‘Text.’ You can then turn Use custom display back off, commit the changes, and the icon will no longer be tied to the rectangle. In reality, this is no worse than the Classic situation, and Helix 6.2 has been improved to always report these uses in the “Where Used” window for an icon, making it easy to track any stray references down.

It should also be noted that it is possible to set the custom format of a rectangle to the same as the default format of the icon. Although that seems redundant, it ensures that the rectangle display is unchanged even if the format of the field changes.

Helix 6.2 and Rectangle Format Discrepancies

Helix 6.2 exposes a bug in old versions of Helix that caused rectangle formatting data to be stored incorrectly. This results in the format of some rectangles changing when a collection is opened in Helix 6.2. Fortunately, there is a fairly simple fix.

In Helix, you can format a field or abacus in two places: the first is the icon itself, and the second is by setting a custom format for a rectangle on a template. The bug is this: when the format of the icon was changed, the two places could sometimes go out of sync with each other. That in itself should not be a problem, as there is a flag (the “use custom display” property) that is used to signal which format should be used.

Or at least, that was the intention. What we have discovered is that older versions of Helix could get confused and use some formatting data from the icon and other data from the rectangle, and it would attempt to synchronize the two data stores, sometimes without much success. As a result, although you may have gotten older versions of Helix to display your data as you wished, the underlying storage may have been badly messed up.

Now that Helix 6.2 preserves the custom display data even when that property is turned off (so that you are able to quickly restore it by turning the checkbox back on) some of the bad data introduced by older versions is being exposed. This is most often seen in Number and Fixed Point data, where decimal amounts are mysteriously missing.

Fortunately, the fix is simple, if a bit tedious: delete the affected rectangle and create a replacement from scratch. That will ensure that the rectangle does not have faulty custom format data. Actually, for most rectangles you can simply turn on the “use custom display” property and enforce your desired format that way. But if that doesn’t work, just replace the rectangle.