Conversions between blank text and other types changing in 3.21101

[CarlosFigueira]

As announced in the latest blog post, we are changing the result of conversion function (ColorValue, DateTimeValue, DateValue, TimeValue, and Value) when a blank (or empty string) is passed as argument. Here is a summary of the changes (and notice that those changes will only apply to apps with the 'Formula-level error management' experimental feature flag turned on):

Function	Inputs
	Before changes		After changes
	Blank	Empty text ("")	Blank	Empty text ("")
ColorValue	Blank	<error>	Blank	Blank
DateTimeValue	Blank	<error>	Blank	Blank
DateValue	Blank	<error>	Blank	Blank
TimeValue	Blank	<error>	Blank	Blank
Value	0	<error>	Blank	Blank

The change to the Value function is the more important one, which is why we wanted to have a broader announcement than what we typically do for experimental features. Odds are that the great majority (almost all?) of the apps will not be affected by this change, but we want to be safe and let you know that this is coming.

A little bit of history

Errors and Power Apps don’t have a long history: in the beginning, there were no errors. Any time an expression would hit an error condition, it would return a blank value. If the app had a label with the following expression in its Text property:

"Sqrt(" & TextInput1.Text & ") = " & Sqrt(Value(TextInput1.Text))

It would display the square root of the value entered by the user. But if the user entered a negative value, then the result of the Sqrt function would be a blank value, and an empty value would be shown in the label.

For errors that are shown in controls on a screen this is an acceptable behavior. However, when we are sending such values to a data source this can become a problem: since blank values represent errors, how do we send blank values to a column in a table, for example, to indicate that the value does not exist?

This led to the introduction of the “Formula-level error management” experimental feature some years ago – where instead of having blank results, errors would be a special value, which could be validated with functions such as IsError and IfError. With “real” errors in the apps, blank values could be sent to data sources, and errors would not.

Minimizing the pain

After the feature was introduced, we realized that there were many places where, if we wanted to have a consistent error story, we would need to make some breaking changes. Since this is an experimental feature, we are allowed to do so, but we always want to reduce the friction for makers that are using it. One of the examples was the change made in the released version 3.21063, where we wanted to expose multiple errors in the IfError function, and we renamed the record variable ‘ErrorInfo’ inside that function to ‘FirstError’ (and added a new variable called ‘AllErrors’). That type of change (renaming variables) can be handled automatically by the platform, which we did – if you had an app from a previous version that was using an expression like

IfError(Patch(MyTable, MyRecord, { Value: 1 }), Notify(ErrorInfo.Message))

When the app was opened in a newer version, the expression would be updated to

IfError(Patch(MyTable, MyRecord, { Value: 1 }), Notify(FirstError.Message))

There were a couple of other changes in that release that we could not fix automatically: the error properties ‘Control’ and ‘Property’ were removed, replaced with two new properties (‘Source’ and ‘Observed’), as they better align with the vision of Power Fx which can be used outside of Canvas apps, in platforms that don’t have the concept of controls. If apps were using those properties (which were not many), they would see errors, and would know that they would need to update their expressions.

Conversion errors are subtler

And that brings us back to the change from this release. Power Fx has many functions that can convert from text values to other types: ColorValue, DateTimeValue, DateValue, TimeValue, and Value. How they handle blank values is not consistent (sometimes they return errors, sometimes they return a valid value, sometimes they return a blank value). This is a problem because in many apps, text input controls are used for users to input data that is converted to those other types. Changing the behavior of those functions won’t show any errors at first that the maker can see and fix right away – they may go unnoticed until later. The Value function is even more problematic because it is used by default in data cards in forms that are associated with numeric columns from data sources (the ‘Update’ property of those cards is typically defined as ‘Value(DataCardValueXX.Text)’). Since we do want to allow apps to store blank values in those columns, if a user clears a text input corresponding to a numeric column, the expectation is that it will clear the value from the column (i.e., use blank).

After a long debate on what semantics we thought was correct, we decided to introduce the above-mentioned changes. This aligns with the philosophy of other Power Fx functions, which treat blanks and empty strings the same way, and we believe it will provide a better app-making experience moving forward.

And this is where we stand now. This will be the last "major" breaking change in this feature, which we plan on moving it to a preview state soon. And as mentioned in the blog post, please send us your feedback!