Unsaved Property of Edit Form Is Always True

[mdevaney]

The Unsaved property of my Edit Form form always has a value of true, even when I have made no changes. My form is in FormMode.Edit.

As a test I created a button with this code in the OnSelect property.  The Edit Form still shows Unsaved as true after I click the button

ResetForm(Form1);

---
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up." 

[ahoepfner]

@mdevaney, @WarrenBelz, @v-bofeng-msft, @Avinoam, @james_hathaway, @subsguts, @mmook, @appyourdata, @biterbit, @sguthrie1, @Matren 

(This is my first post and I don't know etiquette. I tagged everyone on this post to make sure you would see this potential solution.) 

I made a major breakthrough on this issue yesterday. I haven't completely solved it - there's still one form giving me issues. But I think I'm headed down the right path. I wanted to see if posting my solution would help anyone else and if maybe someone could help me with this one last form I'm having trouble with.

I created what is basically an HR app for our managers to track monthly check ins with each of their employees. This is a canvas app using Dataverse for the data. Each table allows entries to be tracked by date, and there is a table for pretty much every question: how can our company better support you; do you need additional tools and resources for your job; what is your definition of success; etc. I have a pop-up that comes up when someone tries to navigate to a new page without saving their edits or their new entry first. I have this tied to the "Unsaved" property of each form. 

All of my forms have a hidden lookup field to link the entries to one employee from the Dataverse User table. This was the first field that was affecting the "Unsaved" property. My lookup formula is in the Default property of the user lookup data card. I added an If statement so that it only does the lookup if the FormMode is New. If the FormMode is Edit or View, it shows the existing entry. This solved the issue for all of those tables with just the one hidden field.

I was still having issues with one large table that has two additional hidden fields. On this screen, I have ten different forms that all link to one master table. One of the hidden fields selects one of five dropdown items ("Pillars") depending on what is visible on the screen at the time, and the other hidden field selects whether or not the entry is in a supervisor or employee form, based on which form it is entered in. I tried adding my If statement on these but couldn't get it to work. I was pretty sure it was the syntax I was using and finally figured it out yesterday. I'm still fairly new to Power Apps, and I realize that there are likely better ways of solving this, which is another reason I wanted to post it here.

My Pillar field is a lookup to a Dataverse Choice table. In the PillarDataCard default, I just have ThisItem.Pillar. In the DataCardValue, in Items, I have Choices(chPillarChoices) and in DefaultSelectedItems, I have 

If('frmIntegrity-Emp'.Mode=FormMode.New, Filter(Choices(chPillarChoices), Value=chPillarChoices.Integrity), [Parent.Default]). I originally was trying "ThisItem.Pillar" instead of [Parent.Default], and that still wasn't working. I tried "Parent.Default" without the brackets, but that wasn't working either. I happened to notice that another combobox had brackets around "Parent.Default" that identified it as a table instead of a record. As soon as I added the brackets around it to make it [Parent.Default], my unsaved property worked!

My Yes/No Supervisor field was similar, but the syntax was slightly different. In the DefaultSelectedItems for the DataCardValue, I ended up with this: 

If('frmIntegrity-Emp'.Mode=FormMode.New, Filter(Choices('Supervisor Comment (chPillars)'),Value='Supervisor Comment (chPillars)'.No), [Parent.Default])

What I think was happening, when my forms would open to an EditForm with an existing entry, those default values were overwriting what was already in the table, even though they were the same value. So it was triggering the Unsaved even though there were no visible changes. 

As I said, I still have just one table that is giving me issues. It's built almost identically to another table that is working just fine, and I can't seem to find where it's getting tangled up at. But after getting the Unsaved property to work everywhere else in my app, I'm feeling confident that I'll find it eventually. It does have one other Yes/No combobox - I don't have default set in the app, but I'm wondering if the default "no" that pushes from Dataverse is affecting this and I'm going to try to add an If statement similar to what I have in my SupervisorDataCard to see if that fixes it (weird that my other form with a similar combobox is NOT giving me issues though).

I hope this helps someone! I am still learning Power Apps and feel like I kind of flail around searching Google for solutions to cobble together for my unique situation. I was pretty excited to have found a fix for the Unsaved property and wanted to share it to see if this community could use it and build on it.

Thank you!

Amy

[subsguts]

Be wary of this because Unsaved doesn't not work all the time.  The reason not to use it is that it can't be TRUSTED and probably never will based on the time it's been and nothing has been done to resolve it.  

As someone else mentioned, I have a big manual comparison between every field on the screen and the original datasource.  However, even that can sometimes fail if you are using combo boxes and other things that get loaded from a source that isn't quick.  The reason being is because during the load, that second or less, the values between the datasource and the screen will be different, so you can get a flash of the "Save" button being available.  Very annoying...  So you have to sometimes rework, as I did, your combos to work off of collections to avoid going to the server.  Again, shouldn't be this hard.

Only other way is just to ask the user the annoying, "Are you sure you want to leave, you may have made changes?".  I noticed that even PowerApps does this when you haven't made any changes, so that's the approach MS has taken.  I don't like it and prefer the system to let the user know immediately that they just changed something that needs to be saved if they don't want to lose it and then I even force them to click a Cancel Changes icon.  Of course they can leave the App, nothing I can do to prevent that.

Hope this is helpful.

[Gurdy]

My solution:
i set a global variable: isFromChanged.
In every textfield or combobox which is relevant, i do an UpdateContext in the OnChange-value:
UpdateContext({isFormChanged: true}).
For me it works to set the visibility or displaymode or color of a save-button for example.
Enjoy.

[subsguts]

I believe this won't be triggered until you leave the "textfield" so it won't trigger until you move to the next field.  I could be wrong.  Not saying it won't work, but if you start typing a change to say a "Descripition:" field, I'm not sure it will know anything has changed if you exit the screen before leaving the field.

[gregmck]

Came across this thread while trying to build a Template App and experiencing the .Unsaved issue.

Adding a label to view the Form's Unsaved value really does lead to some pretty remarkable true / false returns, for no apparent or logical reason.

Not sure if this helps, but the simplest workaround I've found is to check if the User has clicked an UpdateContext link, on their way to the Form, where editMode or newMode have become "true". If so, a Save button / icon can effect the changes; a Cancel button / icon can reset the modes.

Navigation away from the screen is dependent on an And(!editMode, !newMode) condition. If true, navigate. If false, check the .Unsaved property (pretty much as a last resort!). The DisplayMode of the navigation icon is also 

Or(editMode, newMode)-dependent.

Basically, use a Form, but ensure that the User is forced to either Save or Cancel, and make sure the correct contexts are set.

[ClayCollins]

This worked for me as well. I've got the OnChange property of all the fields (Text Input, date picker, and toggles) as

UpdateContext({varEditFormChanged: true})

And I have the Screen.OnHidden property as 

UpdateContext({varEditFormChanged: false})

[ClayCollins]

I think once you click on another control (like a save/cancel/delete/back icon) it will update the variable. Otherwise, you can edit the set it in the OnSelect property rather than the OnChange. It would be a bit more sensitive, but certainly way simpler than doing come super complex comparison logic for each of the fields. 

[subsguts]

Unfortunately, I wanted to have the user see a "Save" icon appear as soon as they change any field.  Not after they have left the field.  Therefore, no use of the Unsaved property works and moreover works consistently.  Therefore, I manually build this out and it's not as bad as it sounds and then you have complete control.  The only problem you can run into is that because communicated with SharePoint online is slow as...... molasses (LOL), sometimes the Save icon will appear for a second while the data loads because it thinks the data in the fields is different from the item you selected in the gallery.  Most of the time this can be eliminated by loading the data into a collection and using that as the source for you lookups/combo box items, etc.   It's when you go to the server/SharePoint, anywhere external the lag is enough to cause the unwanted effect.

The one place I've not been able to work around is when you call Office365 Users for your people picker fields.  Since it's not impossible, but ill advised, to create a duplicate of your company's Outlook directory in a collection, that one still causes the glitch of it thinking you have data on the screen that is different than what is in SharePoint.

Just sharing in case anyone has some genius around the lag and how to eliminate it in this last case.

Thanks

[ClayCollins]

How were you able to create a duplicate of Outlook Directory functionality in PowerApps at all? I was googling so so much, trying different things, followed a couple of different tutorials, none of them worked, and one of them actually caused a bug which required me to roll back a version (something about a circular reference to a variable, if I remember correctly). 

[subsguts]

You'd have to build a large collection in parts.  Each part being less than 2000 people.  There are other articles about how to build a collection > 2000 records.  As I said, I don't think it's impossible to do, but most would say you should use the O365 functionality provided.  It's just slow to refresh the data per the default code because it has to do a lookup using the O365 function and that leaves enough time where the field on the screen is blank, yet the selected item in the gallery has the data.  Therefore, when a comparison of what is in the gallery to what is on the screen will be different for 1-2 seconds sometimes causing it to believe the user has made a change to the name.  Using collections eliminates this lag time as this has also occurred on other fields where I have had the default doing a look-up into a list and changing it to a collection already loaded ahead of time eliminate this issue.

Good luck