I'm curious why OnVisible seems so variable in its operation. I have this in the screen's OnVisible:
The PasswordBox is visible and the BackButton is invisible. I can sort of change them by changing the above true/false and they appear/disappear in the designer (sometimes) but they never match what's in OnVisible at run time.
The other issue is the default value for the Toggle. It's whatever it was when the screen was closed so it's not possible to start the screen as it should be each time as it remembers where it was before. This is when running the screen from the designer. So it's not possible to test the screen as there doesn't seem to be a way to "reset" it. It all seems to be linked to the screen's OnVisible not overriding the other controls. The Toggle leaves showPasswordBox = true when the screen exits and OnVisible fails to set it back to false.
Solved! Go to Solution.
I think perhaps it may be down to not being able to test a PowerApp screen in isolation. The screen gets passed in a variable from a previous screen which it has to display but when running the screen direct from the designer nothing really works. The flow is all wrong, UpdateContext doesn't work, the Reset property of controls doesn't work. When accessing the screen from the previous screen it appears to work fine. So I suspect you can't test screens that are being passed variables in the context. In this case the screen expects a 'student' object obtained from the DataSource and displays student.id. I suspect this might be causing an NPE in the background and causing the screen to fail completely but that's just the programmer thinking out loud!
By "the screen exits", did you mean exit the whole app, or just exit the play mode to go to edit mode, or navigate to another screen?
Only on the 2nd situation, the UpdateContext won't run. With the 1st one, the variable would be deleted in the app and would create one next time you load the app. The 3rd one should update the status of these 2 variables when you change them and then navigate back to the screen.
Notice that Context variables are scoped to a screen, which means that you can't build a formula that refers to a context variable on another screen.
PowerApps are based on formulas that automatically recalculate as the user interacts with an app. Context variables don't offer this benefit and can make your app harder to create and understand. Before you use a context variable, review working with variables.
yes I think Rick72 has it. I think it's a combination of that and the fact UpdateContext is expecting a varable passed in from a previous screen which is an entry from a DataSource. There are other, very simple scoped variables being set by UpdateContext but I suspect when it fails to find the DataSource variable it 'crashes' and won't do anything else, such as create those locally scoped variables. Is this a bug? I would expect in a no-code framework not to have to think about NPEs but that's what it looks like.
Fill out a quick form to claim your user group badge now!
Find out where you can attend!
Features releasing from October 2019 through March 2020
The largest Power BI, Power Platform, and Data conference in New Zealand