Expression for display name to Form View should be 'Row level"

[Koichi_Tsuji]

I would call this as a bug, as this is totally inconsistant with what we believe.

On the detail view, we are able to change the display name based on value(s) coming from each row, as the expression for display name of detail view is believed to be "row level" 

However, even the form view is presenting the data for "each row", we are not able to use the expression for the same part, which is based on row level.  

This is what we see in the form view at this moment.

 

Appreciate AppSheet dev team to look inside to see why we are currently not able to use the row level expression to change the view display name dynamically, using value from each row.

@takuya_miyai 

[WillowMobileSys]

I agree it should be considered row-level. 

[Fabian_Weller]

@Koichi_Tsuji Thank you for this post. Many people in the community asked for this. I also think this is not consistent. Because you could set every column in a detail view as quick edit and get a kind of form view. And you can still use column values in the view name of a detail view. The view name will change according to the column value.
Why can't we do that in form view?!

Adding @Steve 

[Koichi_Tsuji]

Thank you @Fabian_Weller for your comment here.

I just wanted to add another feature request accociated with this.   We have "Save" system language, which can be localized through UX - localize tab.  "Save" could be only used in Form view across the broad of AppSheet, however, the expressions we can pass to change "Save" are also non-row level ones. There are use cases where we wish to dynamically change the form view name based on the value coming from a row. Currently we are unable to do that, as the expression (row level one) is not accepted to used.....

All in all, to be consistant and get more functional options for the localization, "Save" and other system language could be controlled with row level expression as well.

Cheers.

@Steve 

[Steve]

I suspect the reasoning for the current behavior is that the view display name gives the view a name when used as a primary or menu view. At the point the primary and menu names are generated, no specific row is associated with any view. View names are also regenerated as virtual columns, not in real-time as the user moves between views.

[Fabian_Weller]

That sounds logic. But AppSheet has already solved this problem in detail view.
You can set a detail view as a primary or menu view. You can use a column value for the detail's display name. The display name changes according to the column value. So if you use slideshow mode, the view name changes for every row. No sync needed. If you use quick edit, the view name will update according to the column value.
In the primary or menu, the view is called according to the View name (not the display name).
So I think the same behavior could be used for form views: In the primary or menu view use the view name. If you add a new row use the view name. If the row exists, use the display name.

[Steve]

Sounds like this should be a feature idea post, then.

[Fabian_Weller]

Here is a workaround:

https://www.googlecloudcommunity.com/gc/Tips-Tricks/Form-View-display-name-for-add-or-edit/td-p/4331...

[Koichi_Tsuji]

@Steve  Could you please change the category for this post into "Feature request" ?  I m not sure how to deal with it.

@Fabian_Weller   Thanks for the workaround, but what I actually want to get here through this feature request is to make us possible to use [_thisrow].[xxx] expression so that we can use the column value for display name of form view.

Your workaround is interesting, but what I probably would do in your use case could be create two form view, one is for edit, rest of add new row.   Manipulate the actions, one for edit, which will bring the user to form view (for edit). Similarly to make another deeplink aciton to prompt user to another form view (for add). And then we manipulate the Save system language, based on view names.

[Fabian_Weller]

Thanks @Koichi_Tsuji  Yes this is also a workaround. But then you always have to maintain 2 form views. For example if you add a new table or you change the column ordering.  But as you say you want to have control over the save button. In this case having 2 form views is a good workaround.

[Steve]

I don't have the privileges needed to recategorize posts. @Michelle, could you move this topic to Feature Ideas?