Solved

Layout procedure and expression field

  • 22 October 2019
  • 6 replies
  • 360 views
htimmermans
Rank
Userlevel 2
Badge +12

We are using SF 2019.1 since a couple of weeks, and in a project I'd like to add one Calculated field (Expression) and use that value in a layout procedure to dertermine wether to show some fields in the form and/or make them mandatory.

I could be mistaking, but wasn't this possible in an earlier release of the SF? Now I only can set the field available for a Default procedure. The rest, including the layout procedure, are read-only, 

If this was available in a previous version of the SF, and I've used it before, than those layout procedures probably won't compile in this version of the SF. If it has always been this way, why not make the Expression fields available to the layout procedure. Taking a possible performance degradation into account is up to the developer. 

In this case it is a small table, without a view. This way I'm forced to create a view, instead of trigger and what have you...

 

 

 

icon

Best answer by Jeroen van den Belt 23 October 2019, 13:33

View original
Regards, Henri Timmermans Software Engineer @BAS Group

6 replies

Anne Buit
Rank
Userlevel 7
Badge +5

Hi Roy,

The reason the expression is only calculated once is to prevent the logic from going in circles.

Having the expression as default input is basically a sign that there are other fields dependent on the value of the expression. That means that any change in the expression when re-evaluating the expression after the default has been executed would require a re-evaluation of the default logic again.

The current order is as follows:

  • Apply user change to field
  • Clear any dependent look-ups recursively on the changed field.
  • Execute default logic
  • Clear any dependent look-ups recursively on fields that have been cleared by the default.
  • Validate user-editable look-up fields that have been changed by the default and clear them if the default provided a value that may not be entered by the user. Clear any dependent look-ups on these fields recursively if this occurs.
  • Re-evaluate expressions on any field changed by the process described above
  • Execute the layout

For the same reason, expression fields may not have dependencies on other expression fields. You’ll notice other calculated fields will not show up as dependencies and evaluation will fail.

R
Rank
Userlevel 3
Badge +5

A couple of questions come to mind:

  • What is the reason for the order of first Default (with old values for the calculated columns), then recalculation of calculated columns and then Layout with new values?
  • In what way can I determine the order in which calculated columns are recalculated? (I may need the result of a calculation for another recalculation)
  • How do I get the new values of the calculated columns within the Default?
    I have calculated columns that indicate whether the value of a field is correct or not and I want to call tsf_send_message only upon leaving the validated field.
Jeroen van den Belt
Rank
Userlevel 5
Badge +8

Hello Henri,

It is still possible to control the input for expression columns. To do this, you have to make sure that the desired checkboxes for default/layout/context are also checked for the table. Otherwise it will not be possible to edit the input for the columns of that table.

 

 

The order within the behaviour is as follows:
•    Default with the original values is executed.
•    Expression is recalculated. This can lead to new input for the layout.
•    Layout with the new values is executed.

Keep in mind that the default will not be executed again after the expression is recalculated.

I noticed the screenshot of the release note you sent is not entirely accurate. It says that the layout output type is now also read-only for expression columns, but this is not the case (as can be seen in the screenshot). I will edit this in the release notes.

Mark Jongeling
Rank
Userlevel 7
Badge +23

Sneaky but effective :wink:

"Wake me up before you low-code"
htimmermans
Rank
Userlevel 2
Badge +12

Hi Mark,

In the notes only default/layout output is mentioned, not input. And I have checked older versions of our projects and indeed they do use Expression field values in them in some cases. They still work and compile. So what I did was simple…. Use SQL to change the field in de SF database and now I hope this will be viewed as a bug in 2019.1. I'll make a TCP issue of it anyway.

 

 

Regards, Henri Timmermans Software Engineer @BAS Group
Mark Jongeling
Rank
Userlevel 7
Badge +23

Hey Henri,

This indeed has been changed since the 2019.1 version as seen here in the Release notes: https://office.thinkwisesoftware.com/docs/blog/2019/03/19/2019_1.html#changed-sf as last point “Expression columns default/layout output”

Personally, I don't like the change either and wish it will be made possible again.

"Wake me up before you low-code"

Reply


Terms & ConditionsCookie settings