Display names enter Preview for Canvas apps
Have you noticed that when you create a custom field in the Common Data Service for Apps that all the fields start with a random prefix like cr5ca_ and spaces are stripped? For example, the name My Custom Field becomes cr5ca_MyCustomField in a Canvas app.
Have you noticed that spaces and punctuation characters in SharePoint column names become hexadecimal numbers? T-shirt Size becomes T_x002d_shirt_x0020_size in a Canvas app. And yet it looks right on the SharePoint site?
What is going on here is that it’s a good idea to have unique, immutable, concise, no-spaces names for things. These restrictions are common across computer systems helping them to interoperate and are more concise and easier to work with for developers. In CDS these are referred to as logical names.
While these names may be great for computers and developers, they are less than ideal for the rest of us. Tools for picking items rather than always typing them, such as IntelliSense, help compensate for the longer form. For this reason, both CDS and SharePoint also define display names that are much more human friendly, can contain spaces and punctuation, they don’t need to be unique, and they can change over time.
A few months ago we introduced an Experimental feature to use display names instead of logical names in formulas. I am pleased to announce that this feature is now in Preview and is on by default when creating new apps. You can also turn it on for existing apps in the File menu, App settings, Advanced settings, Use column display names (if it doesn’t take immediate effect, refresh your data sources). It is still listed under Experimental but will be moving up to its rightful place in the Preview section shortly.
Honestly, I find it painful to work with apps anymore that don’t have this feature enabled. But if you have any problems or don’t like it you can easily turn display names off with this same switch. Please be sure to let us know what led you to turn it off in the community forum, we’d like to make this feature useful for you.
A useful façade
With this feature the names of columns are displayed and can be referenced using display names instead of logical names. This only has an impact for data sources that offer display names – as SQL Server does not have this concept there is no impact for this data source.
Display names that contain spaces or special characters are enclosed in single quotes, for example ‘T-shirt Size’.
Here’s a simple Gallery control connected to the system Accounts entity in CDS. Without display names we see:
With display names enabled, the names are much more reasonable and match what is shown in the PowerApps portal’s entity editor:
Display names are also supported by IntelliSense in the formula bar. Without display names, many of the selections are cryptic and hard to read:
With display names, much more human readable:
Since display names are not guaranteed to be unique there is the potential for conflict between two columns. If this happens, the logical name of the conflicting column will be shown in parenthesis after the display name. For example, this entity has two columns with Size as the display name, with cr5ca_sizewidth (shown) and cr5ca_sizeheight (not shown) as logical names:
Keeping all the nombres straight
Behind the scenes we always keep the logical names. Have no fear, we never lose track of these important names. These are the names that uniquely identify the column and that we must use when communicating with the data service.
Logical names also help us keep things straight when display names change (they can and do). An important variant of which is authors using different languages. CDS has localized display names in many languages for the system entities.
For example, here is that app from above as viewed by a Spanish author:
And as viewed by an author in Japan:
Note that ThisItem is not changing between languages. Most of the formula language is not localized, only the names of columns will change and the punctuation for decimal numbers, argument separators, and chaining operator.
And I have a secret: you can still use the logical name. We won’t advertise these names in IntelliSense, you’ll need to know what they are. For example, watch what happens up until I type the y in city – no IntelliSense. But once a valid logical name has been entered, the formula is no longer in an error state and the proper value is returned. We don’t advertise in IntelliSense since that would duplicate the names and make a mess, the experience we want is the one when I select ‘Address 1: City’ without needing to type it. Note that we may replace the logical name with the display name when the app is reloaded, especially if you change languages.
One of the reasons this feature has been Experimental so long is that we wanted to cover most places in the Studio where names are displayed. Turns out there are a lot of them. We got most of them but there are still some places where we may drop to logical names:
- Name and DataField property of data cards in the Edit and View form controls.
- Names of columns in the table shaping functions, such as DropColumns, RenameColumns, etc. Here you must still use logical names.
- Collections and variables created from a CDS entity or SharePoint list will use the logical names for the columns.
- The field selector for the Gallery control will drop to logical names if the subject table is involved in a One-to-Many relationship.
We will continue to improve our coverage over time. Until we get them all, please bear with the dual nature of names.
As always, we welcome your feedback! Please use the community forum to share your thoughts.