Page_Header Show columns not obeying Show_If rules?

I’m setting up a multi-page Form view for simple reviewing of a variable number of responsibilities in a task. Basically just forcing the user to see each responsibility and have to click the next button. Here’s how it should look with 3 items:

screengif

3X_4_b_4bc20bb7ebcdb422b44140dcc2dcc7eac49241f8.gif

Since the number of items is variable (max of 10), I’ve set up 20 columns, 10 Page_Header Show columns, and 10 columns to hold the read-only data, which is pulled from other another record with an INDEX( SPLIT(…) , x ) expression. Like so (s=Show, v=Value):

screenshot

I’ve given the Show columns Show_If expressions to only show those pages when there is a value to show:

screenshot

These show expressions are returning the correct Y/N value per record when testing from expression assistant. But something doesn’t seem to be quite right, as it is not showing all of the pages in the form. It doesn’t show any of the pages that include a show_if expression.

For the record shown above, with a text in each ‘v’ column, it should show all 10 pages, plus the last page with the “review” button, but instead it shows this:

screengif

3X_2_d_2d5611629bb143280a6b2d00373a5b069b062168.gif

This “review” Form is part of a larger table, I’ve tested it with the new column ordering in a form, as well as with the old way of using a slice. Same result in both cases.

I can’t imagine what I could have missed, anyone have any ideas? Feel like I’m a little slow today so maybe I just missed something simple.

Solved Solved
0 10 321
  • UX
1 ACCEPTED SOLUTION

Good suggestion @Steve.

I added new columns to pages 2 & 3 “r2b” and “r3b” (‘b’ for ‘boolean’). I removed those 2 pages’ show_if expressions, and moved them to the App Formula for the 2 new columns.

The result confirms that the expressions are working as I’d expect.

3X_0_1_01d96d56294ea8c68cb294a8e43dd8104e52c688.png
3X_f_9_f9137abde716379ead15e2401aff7764723affb7.png



I think my brain finally woke up for today and I’ve thought of a slightly different way to do it that seems to be working.

These responsibilities were recorded in another record as a newline-separated list in a LongText column, a la:

1
2
3
4
5
6
7

So I’m populating the ‘v’ columns with the expression

INDEX( SPLIT( [responsibilities] , "
" ) , x )

Instead of checking whether the ‘v’ column is not blank for the pages’ Show_Ifs, I instead checked the COUNT( SPLIT(…)) against the appropriate number for that page. This resulted in the expected/required behavior.

The [responsibilities] column is higher up in the column list for that table. So it seems like the show_if expressions are evaluating BEFORE the Initial Value expressions for the proceeding fields. I moved the ‘s’ columns after the ‘v’ columns in the spreadsheet, regenerated, but still had the appropriate column order in the slice and it still failed. However if I changed the ISNOTBLANK expression to check against the preceding value (i.e. [r2s] show_if = ISNOTBLANK( [r1v] ) ), then the check works and the page is shown.

Does that make sense?

In (all?) other cases, a show_if expression CAN access data from columns that come after it in the column order. But it seems when it comes to Page-Header Show type columns, it CANNOT.


Just went to my Experimenting app to test in a simpler context:

3X_6_d_6d815a552da81ce8d9e55266c4273bd29b0e71ea.png



Then add in the Show_If


View solution in original post

10 REPLIES 10

Steve
Platinum 4
Platinum 4

I would suggest showing all thee pages, and showing the value of the s and v columns on their respective pages to confirm they’re computing as expected.

Good suggestion @Steve.

I added new columns to pages 2 & 3 “r2b” and “r3b” (‘b’ for ‘boolean’). I removed those 2 pages’ show_if expressions, and moved them to the App Formula for the 2 new columns.

The result confirms that the expressions are working as I’d expect.

3X_0_1_01d96d56294ea8c68cb294a8e43dd8104e52c688.png
3X_f_9_f9137abde716379ead15e2401aff7764723affb7.png



I think my brain finally woke up for today and I’ve thought of a slightly different way to do it that seems to be working.

These responsibilities were recorded in another record as a newline-separated list in a LongText column, a la:

1
2
3
4
5
6
7

So I’m populating the ‘v’ columns with the expression

INDEX( SPLIT( [responsibilities] , "
" ) , x )

Instead of checking whether the ‘v’ column is not blank for the pages’ Show_Ifs, I instead checked the COUNT( SPLIT(…)) against the appropriate number for that page. This resulted in the expected/required behavior.

The [responsibilities] column is higher up in the column list for that table. So it seems like the show_if expressions are evaluating BEFORE the Initial Value expressions for the proceeding fields. I moved the ‘s’ columns after the ‘v’ columns in the spreadsheet, regenerated, but still had the appropriate column order in the slice and it still failed. However if I changed the ISNOTBLANK expression to check against the preceding value (i.e. [r2s] show_if = ISNOTBLANK( [r1v] ) ), then the check works and the page is shown.

Does that make sense?

In (all?) other cases, a show_if expression CAN access data from columns that come after it in the column order. But it seems when it comes to Page-Header Show type columns, it CANNOT.


Just went to my Experimenting app to test in a simpler context:

3X_6_d_6d815a552da81ce8d9e55266c4273bd29b0e71ea.png



Then add in the Show_If


Nice work with the troubleshooting. Yes, it makes sense, and sounds like a bug or limitation of Page-Headers.

Did you try other Show columns? I’m interested if the Show_If evaluation order is different for all Show columns, or only Page-Headers.

Section Headers seemed to work fine.

Yep!

Correct. That’s by design.

What would the goal behind that design be?

I remember @praveen explained it to me once, but I can’t remember the explanation.

I suppose if a user were to make a change to a value inside of a page, and the show_if for that page depended on that value, then that would not be good.

I think you’re on to something lol. They’re saving us the trouble of troubleshooting the disappearing page bug.

Top Labels in this Space