cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Highlighted
BrianR
Level 10

BUG: PowerApps saves app in unusable state - related to SizedBreakpoints

TLDR; Summary

 

  • PowerApps can get into a state where it appears to incorrectly save some settings around SizeBreakpoints where the APP crashes upon startup if loaded outside the studio environment (works fine in studio).  Am pretty sure this is SizeBreakpoint setting related (see below).

  • Once in this state, NOTHING can be DONE about this EXCEPT to toggle ALL the "Screen size + orientation" values, Apply them, and change back and apply.  After this point the app now "works", in that it will sucessfully load and start outside of Studio.

  • HOWEVERdue to another issue (which I'll report in a 3rd post), changing these values causes PowerApps to automatically remove the formulas for the Width and Height properties of virtually every control to fixed numbers (and "real numbers" at that, ie: 727.0 or 623.823).  This WIPES OUT the hard work done correctly enabling the app to be responsive, including resizable (via slider control) panes, etc.  
    And manually fixing all of this would literally take hours (and no guarantee PowerApps won't mess it up again, as it has done many times in the past - but again, this is a separate issue).  

  • Upon exporting the MSAPP files for the unworking and "working" (after changing the size/orientation settings), the AutoRuleBindingEnabled and AutoRuleBindingString properties for the "SizeBreakpoints" properly (in 1.json under Controls) was different.  Attempted to change this in 1.json file and rezip the MSAPP and import, but import failed (also mentioned in previous post, though I have done this many time in the past).  

 

So bottom line, appears that one can get PowerApps into a state with the app where the setting are invalid, and then crashes whenever it runs, and no easy way to fix - other than going back to an older version or starting from scratch app and cut/paste, etc.  

 

Below is some further details...

 

 

I have an app I had been working on that would run fine in Studio, but kept crashing during loading (prior to the first screen being loaded) when run outside of Studio (whether in the Windows Store ("don't call me Metro") version of PowerApps or in a browser running directly off of "Play")  This app now does this 100% of the time and appears to do so immediately prior to changing to the start screen (appears to be after OnStart() has just finished).

 

Here is what I see when this happens: PowerApp Crash on Start.PNG

I had a previously saved version of the app (I make a habit of doing a Save As often so I'll have much older versions in the event I need to test them separately) that still works fine.

 

However, any attempt to use the newer version - even saving as a new name, etc - fails.  I spent several hours literally deleting screens, components, and code until I FINALLY isolated this to a bare app.  

 

After looking at it again and thinking about it, I saw that I had done something probably not so wise in my app while playing with the "responsive" screen sizings - ie: setting App.SizeBreakpoints to a variable that was read from a CDS entity within OnStart().  Unwise as I'm not sure when PowerApps tries to set the breakpoints during startup (even though my app does have "Use non-blocking OnStart rule" disabled).

Changing App.SizeBreakpoints back to its default "[600,900,1200]" and not to a variable, the same thing KEEPS happening.  Its only when I then go into Screen size + orientation, and toggle ALL of the settings (Scale to fit, Lock aspect ration, and lock orientation), hit Apply and change back to the previous values, save and publish my app that now it starts up fine!  So, problem solved, but yet - now ALL of my sizings for my app are messed up as PowerApps "conveniently" replaced all my sizings on my controls on screens from the variables and calculations I had done over the past that worked perfectly - to actual integer (or actaully real number) values - wiping out the formulas (how nice, and far from the first time that PowerApps knack of "self modifying code" has wasted me endless hours).

 

So needless to say this was not the solution I wanted (would take me at LEAST several hours to fix all the controls - fairly complex app).

 

So then I decided to export the "new" working app (after  I changed SizeBreakpoints and then changed all the Screen size + orientation settings), the non-working app, and unzip the MSAPP files, and compare each one (of course knowing that IDs and some of the file names were different so this took some time).  

 

The problem then APPEARED to be in the Controls\1.json file that in my case described the "App" itself.  

 

In the NON-WORKING app a snippet of 1.json is shown below ("pretty printed" using Microsoft Visual Code):

 

 

 

{
    "TopParent": {
        "Type": "ControlInfo",
        "Name": "App",
        "Template": {
            "Id": "http://microsoft.com/appmagic/appinfo",
            "Version": "1.0",
            "Name": "appinfo",
            "IsCustomGroupControlTemplate": false,
            "CustomGroupControlTemplateName": "",
            "OverridableProperties": {}
        },
        "Index": 0.0,
        "PublishOrderIndex": 0,
        "VariantName": "",
        "LayoutName": "",
        "MetaDataIDKey": "",
        "PersistMetaDataIDKey": false,
        "IsFromScreenLayout": false,
        "StyleName": "",
        "Parent": "",
        "IsDataControl": true,
        "IsGroupControl": false,
        "IsAutoGenerated": false,
        "Rules": [
            {
                "Property": "ConfirmExit",
                "Category": "Data",
                "InvariantScript": "true"
            },
            {
                "Property": "ConfirmExitMessage",
                "Category": "Data",
                "InvariantScript": "\"Are you really sure you would like to exit?\""
            },
            {
                "Property": "SizeBreakpoints",
                "Category": "Design",
                "InvariantScript": "gSettings.UI.SizeBreakpoints //[600, 900, 1200]"
            },

 

 

The red bolded section shows that SizeBreakpoints for the app was set to gSettings.UI.SizeBreakpoints (my global variable), but I also saved a version that had this set to simply "[600, 900, 1200]".

 

So the above appeared ok, but the bottom section of 1.json had the following in the UNWORKING code:

 

 

        "ControlPropertyState": [
            {
                "InvariantPropertyName": "ConfirmExit",
                "AutoRuleBindingEnabled": false,
                "AutoRuleBindingString": "false",
                "NameMapSourceSchema": "?",
                "IsLockable": false,
                "AFDDataSourceName": ""
            },
            {
                "InvariantPropertyName": "SizeBreakpoints",
                "AutoRuleBindingEnabled": false,
                "AutoRuleBindingString": "[600, 900, 1200]",
                "NameMapSourceSchema": "?",
                "IsLockable": false,
                "AFDDataSourceName": ""
            },
            {
                "InvariantPropertyName": "OnError",
                "AutoRuleBindingEnabled": true,
                "AutoRuleBindingString": "",
                "NameMapSourceSchema": "?",
                "IsLockable": false,
                "AFDDataSourceName": ""
            },
            {
                "InvariantPropertyName": "OnStart",
                "AutoRuleBindingEnabled": false,
                "AutoRuleBindingString": "",
                "NameMapSourceSchema": "?",
                "IsLockable": false,
                "AFDDataSourceName": ""
            },

Notice here that "AutoRuleBindingEnabled" is set to false and "AutoRuleBindingString" is set to "[600, 900, 1200]".

But in the WORKING code, this section has:  

        "ControlPropertyState": [
            {
                "InvariantPropertyName": "ConfirmExit",
                "AutoRuleBindingEnabled": false,
                "AutoRuleBindingString": "false",
                "NameMapSourceSchema": "?",
                "IsLockable": false,
                "AFDDataSourceName": ""
            },
            {
                "InvariantPropertyName": "SizeBreakpoints",
                "AutoRuleBindingEnabled": true,
                "AutoRuleBindingString": "",
                "NameMapSourceSchema": "?",
                "IsLockable": false,
                "AFDDataSourceName": ""
            },
            {
                "InvariantPropertyName": "OnError",
                "AutoRuleBindingEnabled": true,
                "AutoRuleBindingString": "",
                "NameMapSourceSchema": "?",
                "IsLockable": false,
                "AFDDataSourceName": ""
            },
            {
                "InvariantPropertyName": "OnStart",
                "AutoRuleBindingEnabled": false,
                "AutoRuleBindingString": "",
                "NameMapSourceSchema": "?",
                "IsLockable": false,
                "AFDDataSourceName": ""
            },

had these values to true and "" respectively.  

 

 

Also - as you can see above, in BOTH of these versions of the app, I had watered them down to the extreme where there is no OnStart() (and in fact, only a single simple screen, everything else was stripped out).  

 

So the only apparent difference were the above settings (other than IDs and filenames of the json and resources being different obviously, but the code, controls, etc equivalent).  I used both MS Code and WinDiff to verify the differences in everything else (as well as eyeball checking).

 

I had attempted to modify the 1.json file for the non working one with the values from the one that did and then rezip into an MSAPP and tried to import it (things I have done many times in the past) to see if this would fix things, but the import failed (see my prior message that mentioned these errors).

 

Let me know if you need further info, copies of the apps, session id, etc...

 

 

Helpful resources

Announcements
firstImage

Watch Sessions On Demand!

Continue your learning in our online communities.

SecondImage

PowerApps Monthly Community Call

Next Wednesday, September 18th at 8am PDT

Power Platform 2019 release wave 2 plan

Power Platform 2019 release wave 2 plan

Features releasing from October 2019 through March 2020

FirstImage

Power Platform World Tour

Coming to a city near you

thirdimage

PowerApps Community User Group Member Badge

Fill out a quick form to claim your user group badge now!

FourthImage

Join PowerApps User Group!!

Connect, share, and learn with your peers year-round

SecondImage

Power Platform Summit North America

Register by September 5 to save $200

Top Kudoed Authors
Users Online
Currently online: 47 members 4,495 guests
Please welcome our newest community members: