Different results depending on how properties are read in expressions

Last update: 4 August 2017

Different results depending on how properties are read in expressions

When properties of objects are read in Fabasoft expressions and then used as in-parameters for methods different results can appear depending on the way the properties are read.

  • Option 1: Reading the property via .: The attribute definition of the target attribute is regarded
  • Option 2: Reading the property via
    .GetAttributeValue(, ): Due to technical reasons the attribute definition cannot be regarded

This behavior has practical consequences especially when DATETIME-properties are read as the attribute definition defines whether date and time are stored in local time or UTC.

Example: COO.10.7715.3.7602.TESTSWC@10.7715:testdate was set to 31.12.2008 in GUI.

Reading the property via option 1 and formatting via COOSYSTEM@1.1:Format(...) :

coort.Trace(COOSYSTEM@1.1:Format(COO.10.7715.3.7602.TESTSWC@10.7715:testdate, "yymmdd")[4]);

returns 090101

Reading the property via option 2 and formatting:

coort.Trace(COOSYSTEM@1.1:Format(COO.10.7715.3.7602.GetAttributeValue(cootx, "TESTSWC@10.7715:testdate",0), "yymmdd")[4]);

returns 081231.

The technical background is that the Fabasoft kernel is not able to determine the underlying attribute definition (including the property “Disable Conversion”) and therefore treats the DATETIME value like any value returned from an external ActiveX call.

Conclusio: Reading properties in expressions should be done via option 1 (

.) whenever possible. If it is by any reason absolutely necessary to use option 2 an explicit typecast to the desired attribute definition has to be used. For the example listed above this would look like the following:
coort.Trace(COOSYSTEM@1.1:Format(TESTSWC@10.7715:testdate(COO.10.7715.3.7602.GetAttributeValue(cootx, "TESTSWC@10.7715:testdate",0)), "yymmdd")[4]);