Skip to main content
Solved

Change detection @col parameter not filled.


J. de Lange
Hero
Forum|alt.badge.img+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. 

Best answer by Anne Buit

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.

View original
Did this topic help you find an answer to your question?
This topic has been closed for replies.

5 replies

Mark Jongeling
Administrator
Forum|alt.badge.img+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?


J. de Lange
Hero
Forum|alt.badge.img+4
  • Author
  • Hero
  • 70 replies
  • April 6, 2022

Hi Mark,

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


Mark Jongeling
Administrator
Forum|alt.badge.img+23

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


Arie V
Community Manager
Forum|alt.badge.img+12
  • Community Manager
  • 1032 replies
  • April 8, 2022

@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
Community Manager
Forum|alt.badge.img+5
  • Community Manager
  • 653 replies
  • Answer
  • April 8, 2022

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.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings