Solved

Layout procedure and expression field

  • 22 October 2019
  • 4 replies
  • 71 views

Userlevel 5
Badge +8

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 htimmermans 22 October 2019, 10:53

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.

 

 

View original

4 replies

Userlevel 6
Badge +11

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.

Userlevel 5
Badge +8

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.

 

 

Userlevel 6
Badge +11

Sneaky but effective :wink:

Userlevel 4
Badge +2

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.

Reply