Fundamental change or bug (?) from 3.19104.33 to 3.19111.28

[DerekPapworth]

Today I updated one of my apps, changed since yesterday and was having problems when newly published .. not wishing to bore all with details, I managed to boil down the issue to what seems to be a change or bug introduced between 3.19104.33 and 3.19111.28.

It appears that the Default and/or Reset function has changed (?) when actioned on a control on a different screen in that in 3.19104.33 when a global variable is Set in one screen that a control in another screen has as it's default value, this action is reflected/actioned immediately .. whereas .. now in 3.19111.28 the action isn't reflect/actioned until the screen on which the control appears is visible. This appears to be either a bug or a fundamental change!

As an example, create an app with two screens, on the first screen create a button (button1) to set two global variables _temp1 & _temp2 both to false. On screen 2 create a toggle (toggle1) with it's default set to _temp2 and it's OnChange set to "If(toggle.value,Set(_temp2,false);Set(_temp1,true))" so when this toggle is checked it will set _temp1 to true. Back on screen 1, add a label to display the value of _temp1 (initially false) and add a button(button2) with it's OnSelect being "Set(_temp2,false);Set(_temp2,true);Reset(toggle1)".

When this is saved and run with 3.19104.33 (I used the following url https://create.powerapps.com/v3.19104.33.130671691/studio/ which I found by trawling and wish I'd know before!) then from screen1 pressing the button2 one immediately sees the label showing _temp1 become true .. so the toggle on screen2 has switched on and set _temp1 

.. but ...

When this is saved and run with 3.19111.28 (default now for Studio - again would be good to know what version a Studio is set to?) and from screen1 pressing button2 nothing changes (label still shows false for temp1) but if you then navigate to screen2 then the toggle is switched on and _temp1 is set as can be seen by switching back to screen1.

So it appears that changes to global variables that are used as Default values for controls used to work correctly in 3.19104.33 and are actioned immediately regardless if on current screen or not and yet in 3.19111.28 it's only when the screen (on which a control exists) is visible that the action happens.

Forgive me if I'm missing something but isn't this a major bug or a fundamental change if not?

Hoping for some light being shed ..

Derek

[v-monli-msft]

Hi @DerekPapworth ,

Sorry but I couldn't fully understand your issue. Please explain first. 

In your description, selecting Button2 will only set _temp2 to true, _temp1 will still be false. And you said that the label control displays with _temp1 so, it should still be false. So it seems that the result with 3.19111.28 should be the right one. 

Or did I misunderstand anything? 

Regards,

Mona

[DerekPapworth]

Hi @v-monli-msft 

Selecting Button2 will indeed set _temp2 to true but then _temp2 is the default for for the toggle1 on screen2 so this should then  trigger the OnChange event for toggle1 which then sets _temp1 to true .. with 3.19111.28 this OnChange event is only trigging when screen2 is displayed whereas with prior versions (at least up to 3.19104.33) the OnChange event triggers immediately.

I constructed maybe a better example to explain the issue which I've attached as export package with in this example (TestAppMargin) it's as follows ..  

AppStart:

    Set(_Sales,22);
    Set(_Costs,12);
    Set(_Margin,_Sales-_Costs);
    Set(_Trigger,false)

Screen1:

    s1_Sales (Input Field)
         Default: _Sales
         OnChange: Set(_Sales,Value(s1_Sales.Text))

    s1_Margin: (Input Field - View only)
         Default: _Margin

    s1_Calc (Button)
         OnSelect: Set(_Trigger,true);Reset(s2_CalcMarginToggle)

Screen2:

    s2_Costs (Input Field)
        Default: _Costs
        OnChange: Set(_Costs,Value(s2_Costs.Text))

    s2_CalcMarginToggle (Toggle)
        Default: _Trigger
        OnChange: If(s2_CalcMarginToggle.Value,Set(_Trigger,false);Set(_Margin,_Sales-_Costs))

Note: I know this particular example could've been achieved better/different logic but chosen this way to highlight issue.

So running the App (saved and published under 3.19104.33) the first screen is displayed with 22 in Sales and 10 showing in Margin .. changing the Sales to say 24 and clicking the Calc button the Margin changes to 12 as expected. This is because the Calc button is setting the _Trigger to true and hence triggering the OnChange event of the toggle button on screen2 which is then re-calculating the _Margin variable ..

..but .. when running the App (saved and published under 3.19111.28) and doing the same thing (change Sales figure and click Calc button) the Margin doesn't change .. until .. you switch to screen2 (hence becomes visible) and back to screen1 when it then shows correctly .. so same App reacts different.

So the fundamental change/bug appears to be that with prior platform version(s) the OnChange (and I think Default/Reset) of a toggle control (and possibly other controls not tested) would be triggered when it's Default value changes immediately regardless of whether it's screen is visible .. whereas .. with 3.19111.28 it's only triggered when it's screen becomes visible which is a big problem.

To further explain/demonstrate the issue I've also attached an Excel Spreadsheet showing a similar setup with Sales and Margin on sheet1 and Costs and Margin Calc on sheet2 and with this whenever you change the Sales figure the Margin is of course changed .. the issue with 3.19111.28 is the equivalent of the spreadsheet not recalculating until switching to sheet2 and back again which is obviously a problem!

I think this is a BIG issue and will effect hundreds of Apps that use in any way actions of controls on other screens not visible at the time so hoping for an answer or this is being investigated urgently hopefully.

Thanks! 

Derek 

[sridutt]

Hi @DerekPapworth I am not able to repro issue with app that you attached. We have a fundamental change that loads screens only when required in correct way with latest release. This scenario working previously but not expected flow. Can you please provide your available timing for quick call to sridutt@microsoft.com. I can provide you with options to mitigate your issue.

[DerekPapworth]

Hi @sridutt 

Thanks, I’ll drop you an email over the weekend as to possible times for call (I assume you’re not working over the weekend?) as it’s evening now in UK - I’m assuming you’re US timing?

Derek

[Anonymous]

@sridutt @DerekPapworth 

If possible, could you provide a solution here after your discussions. I use this format in one of my major apps and it's been showing some weird behaviour lately and this could well be the reason? I'm about to troubleshoot this issue over the weekend and I may need to do a total re-design now ... not sure?

Thanks for highlighting this issue @DerekPapworth 

[DerekPapworth]

Hi @Anonymous @sridutt 

I will indeed post outcome and hopeful solution if there is one at this time. I too am thinking I’m going to have to do a total redesign and don’t really want to as I’m still thinking this possible fundamental change goes against the design philosophy of Power Apps. Referring to my earlier analogy/comparison with Excel it’s looking like (just my current impression) this is like reverting to manual calculation of non-visible sheets whereas up until now it’s been autocalc whether visible or not. Let’s hope that’s not the case!

For reference by the way, I’m mainly using this to have common actions (retrieve data, update data, etc) on a different screen so can be “called”/triggered from different screens rather than having to duplicate these actions wherever needed. 

if you get a chance perhaps you could post here how you investigations go over the weekend and if you find similar results to what I’ve found?

Derek

[ShantanuP]

Derek,

Can you please try using previous version to unblock yourself until the issue is investigated?

https://create.powerapps.com/v3.19104.33.130671691/studio/#

[Anonymous]

@DerekPapworth yep, will do

[DerekPapworth]

Hi @ShantanuP 

Thanks, as mentioned in my first post that's what I've done for the moment as I came across the URL for 3.19104.33 by accident under another post. I think it would be useful as a separate point, that URL's for previous version(s) were made more publicly aware as really useful when new version is automatically updated in case of issues like this where users need to revert back to prior working version(s).

Also I'm wondering how many other folks/apps will be affected by this and won't be aware why they're suddenly having problems?

More thoughts on issue itself ..

As @sridutt mentioned, if (?) there is a new (undocumented?) feature that's been rolled that only loads screens "when required" (when navigated to? when ??? definition of "when required" needs clarifying) then a big STRONG suggestion would be that this is as OPTIONAL feature and is controlled at the screen level (for instance, new attribute "LoadOnDemand" against screen with true/false or function result - default being false to not break existing apps) as I can see this would be useful in some apps with many screens to enhance performance maybe to avoid loading and processing all at once.  But there will also be apps (such as mine and possibly @Anonymous that are built on the (existing) logic of PowerApps that controls on different screens react immediately. And I would imagine there will be many cases where it might be good to have some screens load immediately and yet other screens in same app only load when needed .. so setting the option at the screen level rather than app level is vital. 

Also, again if this is a new feature (?) then it looks like it's also unloading the screen when navigated away from as in my example when I navigate to screen2 the toggle OnChange triggers but going back to screen1 and again clicking the button the toggle doesn't trigger until I once again navigate to screen2 so it implies it's been unloaded again?

Hope there's some more clarity on this shortly and also a fix too of course 🙂

Thanks Derek