I ran into an interesting scenario just now. While debugging, I used a Select() function in to OnVisible property of one of my screens. I was copy/pasting a lot of items, and accidentally pointed the Select() to a button which has it's OnSelect property set to a Navigate() function pointing to another screen. Clearly, this is problematic, since I can't get back to the screen now to either delete the button or change the OnVisible formula.
Luckily, this was only a test screen, so it's not detrimental to the app functionality, but if it happened on another screen, it could have been a lot worse. It's also annoying that I now have a useless screen that I can't delete. Is there any workaround to temporarily disable either the button or screen to fix it? I know I can roll back to a previous version, but I'd rather not if there's an easier way.
Solved! Go to Solution.
The way I would fix this would be to use the context menu in the tree view to 'duplicate' the screen that your formula navigates to.
I'd then delete the orginal 'target' screen. If you now attempt to open the screen with the Select formula in the OnVisible property, the call to Navigate will fail because the target screen no longer exists. You can then remove the formula in the OnVisible property.
Finally, you can rename the screen that you duplicated back to the original name. The controls on the duplicated screen will be named differently, but your app should still work. I suspect this approach would be easier than rolling back to a previous version.
The way I would fix this would be to use the context menu in the tree view to 'duplicate' the screen that your formula navigates to.
I'd then delete the orginal 'target' screen. If you now attempt to open the screen with the Select formula in the OnVisible property, the call to Navigate will fail because the target screen no longer exists. You can then remove the formula in the OnVisible property.
Finally, you can rename the screen that you duplicated back to the original name. The controls on the duplicated screen will be named differently, but your app should still work. I suspect this approach would be easier than rolling back to a previous version.
@timl
Thanks, That did the trick. I used a slight variation though in that I deleted all of the controls out of the duplicated screen and then cut/pasted them from the original into the duplicate so that I could retain the original names. Like it never happened!
That's a great tip about deleting the controls on the duplicated screen, and cutting/pasting them onto the original screen to preserve the original names. Thanks for sharing that!
User | Count |
---|---|
123 | |
90 | |
88 | |
75 | |
66 |
User | Count |
---|---|
219 | |
179 | |
138 | |
95 | |
72 |