Set variable to Form.Updates not working

[seadude]

So, I think Form.Updates is broken and has been for a long time. The docs say it should only hold values of changes to a form. Not true for me. Appears to hold values for the entire record.

Goal: To easily detect if changes have occurred to a form being edited.

- I'd like to avoid setting code to every field's OnChange property to detect changes. 

- Especially if Forms *appear* to have a built in function that handles this (Form.Updates).

- Form.Unsaved also appears to be broken. It always returns true for me in an Edit form. Even after Resetting the form.

As a work around, I thought I'd set a variable OnVisible of the form screen to

- Set(varOriginalRecord, Form.Updates).

- Form.Updates is a Record data type. This works fine.

But this does not:

- DisplayMode of Submit button

If(varOriginalRecord = Form.Updates, DisplayMode.Disabled, DisplayMode.Edit)

I get the error: "Invalid argument type"

[amit1030]

@seadude 

You can try replacing the formula with the below formula . Maybe it will work.

If(varOriginalRecord in Form.Updates, DisplayMode.Disabled, DisplayMode.Edit)

If it doesn't work then we can try another way.

Please click Accept as solution if my post helped you solve your issue. This will help others find it more readily. It also closes the item. If the content was useful in other ways, please consider giving it Thumbs Up

[RandyHayes · Accepted solution]

@seadude 

.Updates is a record of ALL of the Update properties of all of the DataCards in your form.  Your observations are not an indication of a broken form...this is how it works by design (and importantly so).  The Updates property should be referenced over referencing individual datacard controls in the form itself...so, if it only represented changed columns, then that would be an issue.

If you want to know if your form has changes, then there is a Unsaved property on the form that can be used to determine that.

The Unsaved property is a powerful property, but highly misunderstood.  Your EditForm will have Unsaved as true is ANY datacard has a difference between Default and Update values on any datacard.  This can be leveraged in many ways.

Need some clarity on it...take a look at my Forms video at 38:21.  That should explain the Unsaved and also the Updates.

I hope this is helpful for you.

EDIT:  Forgot to mention...if your form always indicates it has Unsaved, then you are overriding wither your Default or Updates property in a way that you should reconsider.  

If your underlying field in a form has a value in a Text column with "Happy" in it.  And you were to change the Default in the Datacard to say "Unhappy", then your form will indicate it is Unsaved.  If you likewise do something in the Update property like "Unhappy", this too will indicate you have unsaved changes.

This is NOT broken, this is all working very well and leveraged well also.

[seadude]

Yeah, I already tried in and exactin, no go.

"in" and "exactin" shifts the error to the ".Updates" portion of the expression:

[RandyHayes]

@seadude 

Yes, that will not work and you need not do it...the Form will do all of this for you!

[seadude]

I'd love to use .Unsaved, but it always evaluates to True. Even on a form in ViewMode and EditMode that has never been touched. 

[RandyHayes]

@seadude 

You are adjusting something incorrectly in one of your datacards!  I use Unsaved ALL the time and it works wonderfully.

Here are things to keep in mind:

1) Unsaved will be true on a New record. Because it is new and unsaved!

2) If you have an EditForm that is showing Unsaved as true when you first bring up a record, then you have a formula in one (or more) of your datacards that is changing the Update property.  PowerApps evaluates the difference between Default and Update.  If, for example, you had a Text field and you set the Default to "HI" and the Update to "HI", the EditForm will not recognize that the field has a change.  Anything else will indicate a change if the two properties do not evaluate to the same value.

3) If you cannot immediately spot your datacard that is causing your scenario, then change the Fill property of the DataCard to If(Self.Default <> Self.Update, Red, Transparent)  This will highlight a datacard in red that has a Change.

[seadude]

Hm.... I see now. "If the form has any differences between DataCard Update and Default properties, it will evaluate to true"...

This statement helped me tremendously! I was able to debug the issue by setting each input label to Parent.Default and comparing values. One value was incorrect:

Code for text box Default property was:

If(
    frmProjects.Mode = FormMode.New,
    DateDiff(dtStartDate.SelectedDate, dtEndDate.SelectedDate),
    Parent.Default
)

Fixing it...

If(
    frmProjects.Mode = FormMode.New,
    DateDiff(dtStartDate.SelectedDate, dtEndDate.SelectedDate) & "Days",
    Parent.Default
)

...set Form.Unsaved correctly to False!

Thanks for the clear description of how .Unsaved works. 

[RandyHayes]

@seadude 

That's great!!  Yes, the Unsaved property is a GREAT thing to have.  It gets confusing to find where a conflict exists sometimes.  What I would really love is if each datacard had a Changed property (or Unsaved).  Then it would be easy to recognize changes...or a little faster to find at least.

[seadude]

@RandyHayes , that fill trick is handy. 

It works for all field types except Comboboxes and Attachments. Do you have the equivalent for these two?

**Combobox**

- Sharepoint Person-type column

- Combobox Items: Choices([@LIST_NAME].columnName)

- DataCard Default: ThisItem.columnName

- Update: combobox.Selected

**Attachments:**

Update: attachments.Attachments
Default: ThisItem.Attachments