Solved

Change detection @col parameter not filled.

  • 5 April 2022
  • 5 replies
  • 122 views
J. de Lange
Rank
Userlevel 3
Badge +4

Hi,

I’m struggling with the change detection. It seems that our @col_id parameter doesn’t get filled (always null). In the docs it says that the column will only have a value when the logic is called if the table to which the column belongs, is shown as a detail. 

In our case we display the grid of a table and we have the form of this object under a detail tab. Context, layout and default procedures have no problem reading our @col_id but in the change detection, the value is always null.

I thought the primary key columns of an object would be available and filled when a detail tab is opened or a row is selected. Is this not the case? Is there a way around this? I would rather not refresh all objects whenever one object gets changed. 

icon

Best answer by Anne Buit 8 April 2022, 15:38

View original
This topic has been closed for comments

5 replies

Mark Jongeling
Rank
Userlevel 7
Badge +23

Hi,

...we have the form of this object under a detail tab

What do you exactly mean by this? Is this a detail reference to the same table but only showing a Form or is this a component tab page only having a Form?

On holiday May 6 - May 31
J. de Lange
Rank
Userlevel 3
Badge +4

Hi Mark,

It’s a component tab page only having a Form. Apologies for the confusion.

Mark Jongeling
Rank
Userlevel 7
Badge +23

Only details will get the @col_id values on their detail mapping. The auto-refresh action is per subject, not at component level.

On holiday May 6 - May 31
A
Rank
Userlevel 6
Badge +10

@Mark Jongeling It doesn't get much clearer. Let me rephrase the question we have:

  • Can you provide an example on how to use the @col_id parameter in the Change detection procedure?
    • By using it as filter on the Subject itself
    • By using it as reference_id in a query to check for change in a reference (detail) table
Anne Buit
Rank
Userlevel 7
Badge +5

The parameters are used to indicate the filtered context. Information about active records, user filters and prefilters are not passed to the logic.

In essence, the change detection mechanism provides the same parameters as the badge logic. When you apply a filter to a subject or prefilter to a subject, the badge value is not calculated differently.

Naturally, you can use the @variant_id to consider locked prefilters of the variant in your change detection logic.

 

This results in the following behavior:

When a subject is opened as main subject, none of the @col_id parameters will receive a value.

When the subject is opened as a detail or zoomed detail, the target reference columns will receive a value based on the fixed filters used to display the detail subject.

When the subject is opened as a look-up, the source reference columns will receive a value based on the fixed filters used to open the look-up subject.

 

An example:

When using auto-refresh with change detection on customer directly from the menu, no values will be provided for the @customer_id, @customer_name or @img_combo parameters.

When using auto-refresh with change detection on invoice directly from the menu, no values will be provided for the @invoice_id, @customer_id or @total_amount parameters.

When using auto-refresh with change detection on customer as look-up of invoice, no values will be provided for the @customer_id, @customer_name or @img_combo parameters.

When using auto-refresh with change detection on invoice as direct or zoomed detail of customer #21, the value 21 be provided for the @customer_id parameter. The @invoice_id and @total_amount parameters will not have a value.

I hope this clarifies things a bit.

Terms & ConditionsCookie settings