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." 

[WarrenBelz]

@mdevaney ,

That is interesting and I have had issues with the same test, however I just did a quick on on sample data - the Visible on the label is FormName.Unsaved. Maybe it is the Reset - I would love to hear from others as well.

[v-bofeng-msft]

Hi @mdevaney :

Do you means the value of your Edit Form's Unsaved property always be true?

Through testing, I found a possible cause of this problem:

The value of the Update property of the data card is different from the original record (unlocked and modified the properties).

Test 1:Use automatically generated edit form (without changing properties)

As demonstrated by @WarrenBelz , everything works fine.

Test 2:Change the Default property of a control(use 2 instead of ThisItem.upticks)

My Edit Form's Unsaved property always be true.(Even resetting the form doesn't work)

Test 3:Change the Default property of a control(use 1 instead of ThisItem.upticks)

The value of Unsaved property returns  false.

I think Unsaved property's principle is to verify the value in the UpDate property of all data cards in the form. If it is equal to the value in the original record, it will be false, if it is not equal to it will be true.

Best Regards，

Bof

[WarrenBelz]

@v-bofeng-msft ,

Explains the mystery - thanks - so to clarify, unlocking is not the issue, but changing the Default or Card Update is? Also will it work on cards not changed even if other are?

[v-bofeng-msft]

Hi @WarrenBelz :

Thanks for your summary.

The result of my test is:

• Unlocking is not the issue, but changing the Default or Card Update is.
• As long as the record of the form that will be update at the time is the same as the original record, the value of the Unsaved attribute will be false.

Best Regards,

Bof

[WarrenBelz]

Thanks @v-bofeng-msft ,

@mdevaney  - mystery solved - that is probably workable as a Variable can be set OnChange of the affected cards and this tested also.

[Avinoam]

I have a form with DataSource to SQL server table.

I did not unlock any of the cards and left them as they were created (so the Update property was not changed.

And my UnSaved property is steadily True and doesn't change !!

I get the hunch that it's got to do with SQL being the DataSource 😫

Does any one have a clue?

[james_hathaway]

This has been a MAJOR BUG for many many months now.

There is definitely an error in the Form.Unsaved Property.

I have many occasions where I have changed the Update property of a DataCard, or the Default property of a Card Control - but as long as the Values are the same, then it should validate OK, and NOT set the Unsaved property to true.

Sometimes, this works, and sometimes not, and the really unfortunate thing is that I have not yet found any pattern as to when it works OK and when it doesn't.

(I use SharePoint Lists as a DataSource, but I don't use SharePoint Lookup fields, and prefer to make my own relationships using ForeignKeyID number fields instead. I have also ruled out the old problem with Date fields where it tries to compare the existing value with the "InputTextPlaceholder" property)

Currently, I have to resort to writing very lengthy validation formulas that compares every field on the form with the value currently saved in the SharePoint List, but as some of my more complicated Forms include 50+ fields, these are ungainly and prone to errors or omissions, and kind of makes me question how useful the Form controls are in the first place...

Can someone from Microsoft please update us on when this bug in the Form-Unsaved is going to be fixed?

Thanks

James.

[subsguts]

I have noticed the same thing.  In my case, I am having the Save Icon at the top of my screen only appears when the Form.Unsaved is true.  However, it will sporadically set Form.Unsaved = True as I select different items in the Gallery which reload the record on the form, but there doesn't appear to be a pattern.

An easy way to see this in action is to put a label at the top of your screen and set it to "Unsaved:" & EditForm.Unsaved.  I've done this and you'll see it flash to true as you select different records in the Gallery.

This is MAJOR bug.  In my case this causes flashing of icons and other hidden items whose visible property is dependent on knowing whether items have been changed.

So, I'm in a quandry of either redesigning the whole app (right now the gallery and editform are on the same screen for easy and quick editing) or live with icons flashing every time a user selects the item in the gallery.

IMPORTANT NOTE:  When running in PowerApps this happens less frequently.  If you publish and run from Teams or a browser it is even worse.  I believe this is due to more latency in the data loadeing.

Regardless, Micrsoft, please address this issue as PowerApps shouldn't have this issue and I'm surprised that apps work well without this key piece of functionality working.  The whole point of PowerApps is to avoid writing code, but it appears that the only way to make this functionality to work is to code your own unsaved functionality.  Very frustrating and wondering is PowerApps can really be used at an organization that supports 10000+ users.  It appears this can only be used with a small set of patient users that understand this is really still just beta code and hasn't been fully tested.  I'm really stuck here as I'm trying to sell PowerApps as a way for my team to build a laundry lists of apps instead of using excel and other less optimal ways that don't include a data source that can be queried, but it's going to be tough if I can't make simple apps work well.

Thank you!

Microsoft, please respond quickly.

[mmook]

Identical issue here. In hindsight (2020) I whould not have build the gallery and form on the same screen with visability toggles.