Specific Column in Header of View instead of key column

[OldNo1]

Hi,

is it possible to show specific column instead of the first KEY column in the header of this view?

Thanks in advance

OldNo.1

[Aurelien]

Hi @OldNo1

On View > the detail view name settings:

[OldNo1]

Hi Aurelien,

thanks for your help. I checked and got this message as soon as i changed to formula input:

This formula is not evaluated in the context of a row, so column values are not available.

Then when i select the desired column from wich corresponding row i want the Value as Header name, i get all the row results of this column in the header. Is there a formula wich i can use for this?

thanks
OldNo1

[Aurelien]

From my perspective, this warning and auto-complete feature behavior in this context is a bug.

@lizlynch , can you report it to the dev team?

Seems to work though:

Here is the result:

[lizlynch]

@Aurelien Thank you for reporting. Will share with the team!

[Aurelien]

Thank you !

Also, can you report that the preview pane does not reflect the change immediately as it used to for the past years, but “one change later” when editing the app? Thanks

[Adam-google]

@OldNo1

is it possible to show specific column instead of the first KEY column in the header of this view?

Do you have anything marked as a “label” column? I think it should normally show the label in place of the key here if there is a non-image label column.

@Aurelien

From my perspective, this warning and auto-complete feature behavior in this context is a bug.

@lizlynch , can you report it to the dev team?

This warning is because view display names aren’t usually shown in the context of a particular row (consider footer buttons or side nav menu). Certain view types like Form and Detail that show one row at a time could be considered to show the display name in the context of a row when the view is active and the name appears in the header, but only having a row context available in these exceptional cases is the reason why the editor behaves this way.

@Aurelien

Also, can you report that the preview pane does not reflect the change immediately as it used to for the past years, but “one change later” when editing the app? Thanks

I’m not seeing that, is it happening for you in every app and every sort of change, or some more specific case? Does refreshing the page have any effect?

[Aurelien]

@Adam-google

This warning is because view display names aren’t usually shown in the context of a particular row (consider footer buttons or side nav menu). Certain view types like Form and Detail that show one row at a time could be considered to show the display name in the context of a row when the view is active and the name appears in the header, but only having a row context available in these exceptional cases is the reason why the editor behaves this way.

Hello @Adam-google

If so, the option Display name should be removed? However I would prefer not

Now I have this, which seems to be worse ?

@Adam-google

I’m not seeing that, is it happening for you in every app and every sort of change, or some more specific case? Does refreshing the page have any effect?

No, and it’s happening on every domain I try it.

Here is a gif capture:

1. inversion of two columns order ==> nothing happens

2. navigating to another view, then getting back to first one ==> change is updated

3. inversion of two columns order, multiple times ==> changes happens with “one change delay”

[Adam-google]

@Aurelien

If so, the option Display name should be removed? However I would prefer not

I think the main use case that motivated a display name expression was for localization, for example looking up a translated name in a lookup table based on something like a user setting choice of language.

@Aurelien

Now I have this, which seems to be worse ?

The warning about “column values are not available” I think also means that the expression binding context that interprets the written expression will be unaware of any column names if you do try to reference them. Perhaps we could allow the references and try to resolve them when we can, with some more nuanced warning that the expression might sometimes be run with no row context, in which case referenced column values would be blank (so you could use something like an IF to account for both situations).

@Aurelien

• inversion of two columns order ==> nothing happens
• navigating to another view, then getting back to first one ==> change is updated
• inversion of two columns order, multiple times ==> changes happens with “one change delay”

A bug with column order was recently reported that might be related. But it sounds like you’re seeing similar lag with other settings as well? Personally I don’t see the problem with column order so far, but maybe only certain accounts are affected.