Given the performance issues caused in my app by Improved Rendering Mode, I set about a big UI overhaul.
In the process I've just discovered a fix for the unpredictable behaviour of autoheight on labels. First of all, the symptoms occur when you're using both autoheight=true and have a condition for visibility. I expect it's a matter of render timing - but regardless, the fix is to also make your autoheight conditional, instead of just true. The easiest way to do that is to use the same code as your 'visible' condition in your autoheight.
Solved! Go to Solution.
Hello @davidstone,
The fix is not strictly related to the nested level, but we could never reproduce this issue with just one level deep. Can you confirm that your gallery is on the regular screen and not a part of the scrollable screen or card? If so then I would appreciate some instructions on how to reproduce this in a new app.
Thank you,
I love this idea, but PowerApps isn't allowing me to change the AutoHeight property of my labels? I can neither change the AutoHeight property to label.Visible or the code I use to toggle visibility, If(tog.Value=true,false,true). As soon as a change the property and switch away it reverts to either true or false.
Please note that we've identified and fixed an issue with the autoheight label when it is nested 2 levels deep in a container that has "visibility" formulas. For example, a label that is added to a flexible height gallery, which is added to another flexible height gallery that has a formula assigned to its "Visible" property. Following the normal release schedule, the fix should be publicly available on the week November 12th.
Sounds great! Will this effect labels just one level deep? In my case the issue you've described a fix for actually occurs within just a single gallery with conditional visibility on a label - no nesting required.
Hello @davidstone,
The fix is not strictly related to the nested level, but we could never reproduce this issue with just one level deep. Can you confirm that your gallery is on the regular screen and not a part of the scrollable screen or card? If so then I would appreciate some instructions on how to reproduce this in a new app.
Thank you,
I've got another fix for this - since the previous fix hasn't worked consistently for me.
Instead of having conditional visibility on my label (which, whether directly causative or not, makes the symptom occur), I have a condition on the x position. So instead of hiding the field, I simply position it to a negative x value which is off screen. Same result, but now the field properly displays at the right height.
And with that, I have decided to finally switch to Improved Rendering!!
Hi @dinusc,
To re-create my issue:-
I don't know, but I would guess this is something to do with the timing of the height calculation vs when the conditional visibility is displayed? I further suspect this because in another app I was able to set the height property of a field to a context variable, then use a timer to alter the context variable, after which the correct autoheight was calculated after the visibility.
Some of those steps aren't strictly necessary, such as collecting the ID of the item clicked. I'm only doing that because in my app you can 'expand' multiple rows.
I tried this and a couple other suggestions, but what worked for me was this:
It's working for me, i used the same formula of the visibility in autoheight and worked.
User | Count |
---|---|
122 | |
87 | |
86 | |
75 | |
67 |
User | Count |
---|---|
214 | |
181 | |
137 | |
96 | |
83 |