Everything Else
Bug Fixes in Helix 5.0.2
Conditional Color

Even though no code changes had been made to conditional color code in versions 4.5.3 through 5.0.1 of Helix Client/Server, it has been reported that conditional color behavior was changing from version to version. To be frank, the code in Helix that drives this feature was not very well thought out, nor is it well implemented. There is still much work to do to bring the conditional color feature to the level of performance we desire, but this version should result at the very least in all collections functioning consistently. Some “new code” was added (i.e.: handling rectangle frames) but it was determined that an attempt to completely correct the problems with conditional color would delay this release beyond reason. Helix 5.0.2 represents our first attempt to address this area of the Helix code.
Also note: the term “conditional color” is a bit of a misnomer. Because you can also change font, size, style, and other attributes (as well as color) of text within data rectangles, the term “conditional attributes” will be used in these release notes to refer to what has historically been termed “conditional color.” the term “conditional color will be used only in instances where font data is meaningless (e.g.: frame and background color).

  • Rectangle Frames Did Not Reflect Specified Conditions(D360)
    In all versions of Helix prior to 5.0.2, conditional colors assigned to rectangle frames were ignored. This has been fixed: conditional color applied to the frame of a rectangle will now properly change the color of the frame.
    Note: Because it was possible to specify frame colors in prior versions of Helix — even though there was never any code in Helix to conditionally change the frame color — it is possible that a collection designer may have specified conditional frame color changes even though they would have no effect. If you see rectangle frames appearing in an unfamiliar color in Helix 5.0.2, check the conditional attributes that are specified for that rectangle’s frame.
    Because Helix draws objects on screen in “left to right, top to bottom” order, rectangle frames that butt up against adjacent frames may not draw as expected.
  • Color Fails When Scrolling Lists: Client/Server Only (D358)
    The specific problem addressed here is the behavior that occurs after a list is initially drawn on screen. Conditional attributes were correctly applied to the records seen in the initial screen of information, but scrolling from page to page (or even using the Collapse Box to collapse and expand the view) would result in inaccurate conditional attributes in the data rectangles. This has been fixed, and there should be no cases where scrolling from place to place in a view will result in inaccurate conditional attributes being displayed.
Fixed Point multiplied by 0 = undefined (D625)

Beginning with version 4.5.3 of the Helix products, when a Fixed Point field is multiplied by 0, the result is undefined. It now returns 0, returning Helix to the behavior of versions prior to 4.5.3.

Edit Keys Fail When View is First Opened (D691)

In Helix 5.0, the edit keys (Page Up, Page Down, Home, End) did not work correctly when a list view was first opened. It was necessary to click in the view before they would work. This has been fixed.

Helix RADE is not Remote High Level Events Aware (D695)

Helix RADE 5.0 was inadvertently compiled with the “Accept Remote High Level Events” option turned off. This prevented some third party applications that use Helix’s Apple event mechanisms from working properly. This has been fixed, and now all Helix products accept both Local and Remote high level events.

Lookups to Constant Data Inaccurate on Open Lists (D682)

Further discussion and current status.
Note: v5.0.2 does not completely solve this issue. Although it has not been fully corrected, results are greatly improved. At this point we still suggest using the workarounds outlined below.
In Helix 5.0 & 5.0.1, a rare combination of factors contributed to a difficult to fix bug. Specifically, if data on a list was based on values that were derived from a lookup tile that used a constant (typically username or true) the data in that list would not always correctly update the list if it was open at the time the data was changed. This could be worked around by using a “Max value for constant = constant” construction, or by closing and reopening the list, but the code should have worked as expected.