Testing calculate field on CHT 4.1.0

Technical Support
1

I have a calculate field in my form whose value is as follows:

if(selected(${child_vomit},“yes”) or
selected(${child_convulsions},“yes”) or
selected(${child_lethargic},“yes”) or
selected(${child_fever},“yes”) or
selected(${child_severe_diarrhea},“yes”) or
selected(${child_difficulty_fast_breathing},“yes”),1,0)

The calculate field is used to show/hide certain sections of the form. If the calculate field is relevant during form submission, then all the sections that use this field as a relevancy condition are shown. However, if the calculate field become irrelevant (ie the path taken in the form does not trigger it), then the subsequent sections do not appear. How can I fix this?

2

I see you mentioned on CHT 4.1.0. Did this form behavior work as expected with 3.x, but it has changed in 4.x or is this just a general form behavior question?

In general, the value of a non-relevant field should not be referenced by other relevant fields. Some of the complexity here can be avoided by just putting the calculate at the top-level with no relevant expression so that its value is always calculated.

In this case, I am also curious if perhaps you are running into one of the know issues we have documented for 4.x where there is an inconsistency between what is displayed in the form vs what is saved in the report…

3

@jkuester, it worked fine in 3.15.

Here’s the link to the form. Please check the

refer_child_danger_sign_flag.

.

4

Resolved by checking for refer_child_danger_sign = null in addition to checking for refer_child_danger_sign = 0.

2 Likes
5

if the calculate field become irrelevant

When you say “the calculate field” are you talking about refer_child_danger_sign? Do you have down-stream expressions that depend on this field that will be evaluated even if refer_child_danger_sign is non-relevant?

If this is the case, then I think you should consider refactoring your form logic. IMHO it is an ODK form best practice to only use fields in an expression when you know those fields will be relevant when that expression is evaluated. When a field in an ODK form is non-relevant, the implication is that its value does not matter. (This becomes especially important when trying to deal with the behavior caused by the issue that I linked above.)

If possible, the most simple way to solve this issue would be to make the refer_child_danger_sign always relevant (or at least always relevant whenever it will be used in an expression). It will have a default value of 0, which I believe would result in your desired behavior. Another way I have refactored forms in situations like this is to add a new calculate field (e.g. global_refer_child_danger_sign) that is always relevant. The expression for this calculate can use the coalesce function: coalesce(${refer_child_danger_sign}, 0) (or your above-mentioned null check). Then, any expressions that could reference refer_child_danger_sign when it is non-relevant should be updated to just point to global_refer_child_danger_sign. This will help you avoid proliferating the null checks throughout the form.