Search

 

User:Developer

Prerequisites

- not applicable

Introduction

New Futurama releases are backwards compatible. In some situations changes in the Futurama behavior are made that may break existing applications. In this topic is explained how this is solved within Futurama.

 

Description

In a new Futurama release it is important to ensure backwards compatibility. In some new Futurama releases changes in the Futurama behavior lead to compatibility issues. At this page these issues are treated. A Compatibility mode property is introduced in order to guarantee backwards compatibility. This is explained in the second paragraph below. First for several Futurama releases a list is given with the compatibility issues. This list can be used in order to determine whether a specific compatibility issue is relevant for your application.

When upgrading your current Futurama version to the most recent released version make sure you check the successive releases and compatibility issues.

Compatibility issues and conversion

Mentioned below for the Futurama releases the compatibility issues.

Futurama 24.02

  • For this version a new Compatibilty mode (‘24_01’) is introduced. See paragraph ‘Compatibility mode’ for detailed information.

Futurama 20.11

  • For this version a new Compatibilty mode (‘20_10’) is introduced. See paragraph ‘Compatibility mode’ for detailed information.

Futurama 20.01

  • For this version a new Compatibilty mode (‘19_12’) is introduced. See paragraph ‘Compatibility mode’ for detailed information.

Futurama 18.03

  • For this version a new Compatibilty mode (‘18_02’) is introduced. See paragraph ‘Compatibility mode’ for detailed information.

In this version the Visible property for a User Interface Object (UIObject) is changed from a boolean to a Variable of type boolean.

Existing Actions created in a Futurama version before 18.03 are automatically converted to the new structure as far as possible. There are a number of different situations:

  1. The UIObject for which the Visible property is set by the Action is Public: in this situation the Action is not converted; Documents containing this situation will be set to Compatibility mode Futurama_18_02.
  2. All of the next situations apply:
    - the Action setting the Visible property for the UIObject is in the document structure directly before the UIObject (no other Futurama objects are defined between the Action and the UIObject)
    - the UIObject is not public
    - the variable that sets Visible is of type boolean
    - the Action setting the Visible property for the UIObject does not have a Condition
    - the Action setting the Visible property for the UIObject only has one child (i.e. the Variable that sets the visible property)
    - the UIObject is only set by only one Action

    If all these situation apply and the Action has a Variable without relative references as child, the Visible property of the UIObject is changed into the Visible variable and the action is deleted. If all these situations apply and the Action has a Visible variable that contains relative references, the Action gets a condition false and the Visible property of the UIObject is changed into a reference that points to the Variable. 
  3. When situation 1 and 2 do not apply a different conversion is done. In this situation in the Futurama document a ‘conversion to 18.03’ folder is created with UserVariables for each UIObbject for which the Visible property is set by an Action for which situation 3 applies. Within the Action that sets the Visible property for the UIObject a ChangeValue is created. This ChangeValue has as TargetUserVariable the UserVariable that is created  for the UIobject in the conversion folder. The data that is set in this UserVariable is the Variable that is within the Action. Furthermore the Visible property of the UIObject refers to this UserVariable. 

Futurama 17.12

  • For this version a new Compatibilty mode (‘17_11’) is introduced. See paragraph ‘Compatibility mode’ for detailed information.

Existing XMLConverters created in a Futurama version before 17.12 are automatically converted to the new structure as far as possible. There are a number of different situations:

  1. The XMLConverter is Public: in this situation the XMLConverter is not converted;
  2. All of the next situations apply:
    - the Action setting the data for the XMLConverter is in the document structure directly before the XmlConverter (no other Futurama objects are defined between the Action and the XmlConverter)
    - the XmlConverter is not public
    - the Action setting the data for the XmlConverter does not have a Condition
    - the Action setting the data for the XmlConverter only has one child (i.e. the XmlBuilder that sets the data)
    - the XMLConverter only has one Action that sets the data

    If all these situation apply and the Action has an XmlBuilder as child, the condition of the Action is set to false and the Data property of the XMLConverter refers to the XmlBuilder. If all these situations apply and the Action has a Reference to an XMLBuilder, the Action is deleted and the Data property of the XmlConverter refers to the target of the previous mentioned Reference. 
  3. When situation 1 and 2 do not apply a different conversion is done. In this situation in the Futurama document a ‘conversion 17.12’ folder is created with UserVariables for each XmlConverter for which situarion 3 applies. Within the Action that sets the data for the XmlConverter a ChangeValue is created. This ChangeValue has as TargetUserVariable the UserVariable that is created  for the XmlConverted in the conversion folder. The data that is set in this UserVariable is the XmlData that is within the Action. Furthermore the Data property of the XmlConverter refers to this UserVariable. 

Futurama 17.11

For this version a new Compatibilty mode (‘17_10’) is introduced. See paragraph ‘Compatibility mode’ for detailed information.

Futurama 17.10

  • For this version a new Compatibilty mode (‘17_09’) is introduced. See paragraph ‘Compatibility mode’ for detailed information.

Futurama 17.07

  • For this version a new Compatibilty mode (‘17_06’) is introduced. See paragraph ‘Compatibility mode’ for detailed information.

Futurama 17.05

  • See paragraph ‘Compatibility mode’ for detailed information. For this version a new Compatibilty mode (‘17_04’) is introduced

Futurama 16.11

  • The names of two Futurama Service methods are changed. If you use Futurama Server by doing a POST HTTP request to Futurama Service this change of names can be relevant for your situation. This method name of StartJob is changed in StartJob2, the method name of GetJobs is changes in GetJobs2;
  • In this version a change is made in the default Futurama javascript file FuturamaScripts.js. This change will not be affected in the situation that a browser caches javascript files and this caching has not expired yet. To force browsers to reload this javascript file change the name of the javascript file to FuturamaScripts.js?v=2016_11. See this page how to change the name of the javascript file. Attention: in Futurama 16.12 this situation is solved within Futurama. So for using Futurama version 16.12 + this change is not needed
  • Some security improvements are made in this version.  See the settings ‘allowSettingUserVariablesThroughURL’ and ‘onlyAllowCallsToVisibleButtons’. Check in your application whether you set uservariables through URL or use invisible buttons for postbacks. In these situations the  default value of this settings will lead to the situation that this functionality in your application will not work. So either change the default values of these settings or (recommended) change your application in order to let it work again.
  • Futurama now automatically prevents Cross Site Request Forgery by adding a security token to every postback request that is made. A postback is invalid if the expected validation code differs from the actual validatin token. In this situation in the Futurama log an error ‘Request validation token x was received, but y was expected. Postback is invalid’ is logged. Check in this situation the network traffic to see which successive postbacks occur and hat causes the invalid postback. An example is the situation that in the web.config of your application users are not allowed to access the Scripts folder. That means that at the login page the FuturamaScripts.js and the Jquery.js cannot be read, causing a couple of postbacks at the login page. Before this Futurama version this same situation occurs, but this didn’t lead to a Futurama error because there was no CSRF check. 

Futurama 5.3

  • See paragraph ‘Compatibility mode’ for detailed information. For this version a new Compatibilty mode is introduced.

Futurama 5.2.1.4

  • See paragraph ‘Compatibility mode’ for detailed information. For this version a new Compatibilty mode is introduced.

Futurama 5.2.1.2

  • See paragraph ‘Compatibility mode’ for detailed information. For this version a new Compatibilty mode is introduced.

Futurama 5.1.4

  • See paragraph ‘Compatibility mode’ for detailed information. For this version a new Compatibilty mode is introduced.

Compatibility mode

Futurama uses the property ‘Compatibility mode’ in a document to ensure backwards compatibility.

Sometimes it is needed to change the behavior in a way that potentially breaks existing applications. When this kind of change is required, and you application contains this changed functionality, only then a compatibility mode is added as property of the Document object. The compatibility of the document is set to the old version. In this way, the old behavior is still supported.

It is recommended that you change the document to make sure you use the latest compatibility mode. You will get a validation warning when you use a document that has a different Mode than ‘Futurama_Current’.

The changes per compatibility mode to be aware of when changing to Futurama_Current are listed below.

Compatibility mode Futurama 24_01

  • In Futurama 24.02 the formula Days360Excel underwernt adjustments to mirror Excel's behavior. There were some mismatches between Futurama and Excel when using the Days360Excel formula with the last day of the month. A new Compatibility mode ('24_01') has been introduced to ensure continuity with previous behavior.

Compatibility mode Futurama 20_10

  • In Futurama 20.11 the behavior that objects XmlNode obtain the results of the evaluation of its XPath has changed. Old behavior was incorrect and was that if the XPath evalution of an XmlNode resulted in an empty nodeset, this XmlNode object held its value of its parent XmlNode or XML source. New behavior is that if the XPath evalution of an XmlNode results in an empty nodeset, this XmlNode object has no value and all of its children XmlNodes and XmlFields have no value, regardless of their XPaths.

Compatibility mode Futurama 19_12

  • In Futurama 20.01 the behavior of the formulas Vlookup and FindPreviousRow has changed. See for examples of the changed behavior at the support pages of these formulas. This is applicable in the situation these formulas are used to find rows in a column of values where duplicate values potentially can exist.

Compatibility mode Futurama 18_02

  • In Futurama 18_03 the Visible property is changed. Up to this version the Visible property could only be filled in Futurama with an action. The new default usage is to use the Visible property on an UIObject to define the visibility. Existing Actions are converted. UIObjects that are Public can not be automatically converted. For these UIObjects  the compatibility level is set to Futurama_18_02. This will ensure the correct behavior of those UIObjects. For documents with Compatibility mode Futurama_18_02 the use of an Action to set the Visible  property is still allowed if the target of the Action is Public. For compatibility mode > Futurama_18_02 you can not set the Visible property of an UIObject with an Action.

Compatibility mode Futurama 17_11

  • In Futurama 17_12 the XmlConverter is changed. Up to this version the XmlConverter could only be filled in Futurama with an action. The new default usage is to use the Data property on the XmlConverter to define the XML to use. Existing Actions are converted. XmlConverters that are Public can not be automatically converted. For these XmlConverters the compatibility level is set to Futurama_17_11. This will ensure the correct behaviour of those XmlConverters. We recommend you to change the behaviour of those XmlConverters manually.

Compability mode Futurama 17_10

  • The XmlBuilder has a Condition property. In some situations the value of this property was ignored. If your upgrade results in a 17_10 compatibility mode, this means you have one or more XmlBuilders with a non-empty condition that was previously ignored. These are conditions on XmlBuilders that are not child of other XmlBuilders. Check the conditions on these specific XmlBuilders. When upgrading to Futurama 17.11 and setting compatibilityMode to Futurama_current, the condition on all XmlBuilders will be respected.

Compatibility mode Futurama 17_09

  • Improved error handling of invalid culture on Windows 10: Futurama allows to configure the regional settings in the format section of the configuraton file. Behavior has changed on windows 10 when an invalid culture is configured. This fix provides improved messages, as well as changed behavior for the formulas FormatDouble and FormatDate when an invalid culture is configured. In case a valid culture is defined the changed behavior doesn't affect your application. Below the old and the new behavior:

    • Old behavior when invalid culture is configured: the result of FormatDouble and FormatDate is null on windows 7,8, but a valid formatted string on windows 10

    • New behavior when invalid culture is configured: the result of FormatDouble and FormatDate is null regardless the OS

  • Up to Futurama 2017.10 it was not possible to use the Round Formula with a negative number of digits. This was resulting in errors and a Null value. From 2017.10 the negative significance is supported. See the support page for examples how to use this Formula. Note that:
    • the implementation of Round with positive significance is unchanged
    • RoundDown and RoundUp already had support for negative significance

Compatibility mode Futurama 17_06

In Futurama 17.07 the behavior of the HashText formula (formerly known as Encrypt) is changed. In this formula the hash is calculated and converted to a string. For MD5 and SHA1 a BitConverter was used for this conversion, for SHA256 a Base64 conversion was used. This inconsistency is solved in Futurama 17.07. Futurama Documents that are created before 17.07 which consists the HashText function are getting the compatibility mode 17_06. With this mode the old behavior is supported. If you have a Futurama Document with the HashText function which only uses MD5 or SHA1 hashing then you can safely set the compatibility mode to Futurama Current. If you have a Futurama Document with the HashText function which uses SHA256 hashing, then it is recommended to change the HashText function to the HashTextWithBse64 function. This function gives the same results as the Hashtext function before 17.07. After changing to this formula the compatibility mode can be safely set to Futurama Current.

Compatibility mode Futurama 17_04

In Ranges a range can be given from a startvalue to an endvalue with a certain step size. Ranges can have type long, double or date. In the situation the type of the range was double, and the stepsize and the endvalue were broken numbers in some cases the endvalue was not part of the Range. For example a range from 0 to 11/12 with step size 1/12. Up to Futurama_17_04 the end value 11/12 was not part of the Range. From Futurama 17_05 this is solved. If the compatibility mode is 17_05, the old behavior is used.

Compatibility mode Futurama 5_3

XmlFields with Rank 0 that have an XPath that returns multiple items returned null, without an exception prior to Futurama 6. Starting in Futurama 6, these fields will throw an exception.

Compatibility mode Futurama 5_2_1_4

Up to this version of Futurama, the function Matrix.Percentile was sometimes incorrect.

For example take the array {2,4,8,3} and calculate the 90% percentile. Up to this version the Percentile was calculated by:

  1. ordening the array from small to large: {2,3,4,8}
  2. first index in the array is 0, last index in the array is n-1 (in this example 3)
  3. 90% percentile is index 90% * 3 = 2,7
  4. interpolation between the values at index 2 and index 3 as follows: 90% * 4 + 10% * 8 = 4,4 

Up to this version of Futurama, the function Matrix.Percentile was sometimes incorrect.

From Futurama version 5.3.0 + the Percentile is correctly calculated by:

  1. ordening the array from small to large: {2,3,4,8}
  2. first index in the array is 0, last index in the array is n-1 (in this example 3)
  3. 90% percentile is index 90% * 3 = 2,7
  4. interpolation between the values at index 2 and index 3 as follows: 30% * 4 + 70% * 8 = 6,8 

In this example a very small array is used to make the difference between the two calculation methods clear. In practice this function will only be used in the situation of large matrices with values that are relatively close to each other, so the difference between those two calculation methods is small.

The Percentile function is repaired in Futurama 5.3.0, leading to a change in the behavior of Futurama. To maintain the original behavior, Compatibility mode 5_2_1_4 must be used.

Compability mode Futurama 5_2_1_2

Up to this version of Futurama, the repeattarget of a loop (XmlBuilder, Action, WebListBox) was not reset correctly at the end of the loop.

Normally, all calculated items in the document structure are not recalculated everytime the value is evaluated. Instead, they 'cache' the calculated values once evaluated. Only when a determinant has changed its value, the cache is cleared, which leads to a new evaluation the next time the item is calculated.

In loops, the value of the repeattarget is set for all values in repeatdata in an iteration. Each time the value is reset, leading to a clearance of the cache of all dependants (recursively). At the end, however, the repeattarget is set to its original value (before the iteration started). In this last step, the cache of its dependants are not cleared. Which is not correct!

This is repaired in Futurama 5.3.0, leading to a change in the behavior of Futurama. To maintain the original behavior, Compatibility mode 5_2_1_2 must be used.

Example:

  1. Open this document in the Futurama Editor
  2. Execute 'test' (ID=2)
  3. Evaluate 'result' (ID=5)

Now repeat these steps using Compatibility mode 'Futurama_Current'

Compability mode Futurama 5_1_4

The formula ‘Index’ for a datatype ‘long’ is changed. The old behavior was that the formula returned a result 0 when the provided index is out of range. In newer versions the function will lead to an exception when the index is out of range. For example: Index(table, –1) will lead to 0 in ‘Futurama_5_1_4’and will lead to an exception in all Compatibility modes later than ‘Futurama_5_1_4’. We changed this behavior to make sure the Index function for a long has the same behavior as for the other datatypes.

Related Topics

- Document: The object where you can set this property.

Feedback

If you have any questions about this subject or if you want to provide us feedback please send us an e-mail.

Updated: 2015-03-31