How can I change the tabbar menu title of form based on if its a new entry/editing an existing row?

AppSheet AppSheet Q&A
1

I have a form on the tab bar of my app for submitting new bug reports, the same form is also used within a different area for editing a bug report.

I want to have the title on the tab bar say “Submit New Bug / Issue”, but if editing a bug, then be “Update Bug / Issue”

I figured since Display name can have a formula it should be easy, just check a value that I know would never be set for a new entry not saved yet, however that gave an error, and I then saw the message on the expression screen “This formula is not evaluated in the context of a row, so column values are not available.”

Given that info, Im out of ideas on how I can make it happen.

For the tab bar I really need the text to be Submit Bug / Issue rather than Bug / Issue, as thats vague and could mean submit new, or it could also mean list of bugs. Im guessing there’s a way to make a second form and do it that way but I was hoping of an easier way

2

So 3 things that I’d do with this

  1. Have a DateTime column called [****Creation] with an initial value of Now(). This give you the second the bug was created
  2. Have a ChageTimestamp column called [****Mod] which will give a DateTime of the last edit. You could possibly try to comapare these two to see if its an edit or creation
  3. Better still, have all the responses to the bug in a subtable

I’m guessing you mean display name for the action button or view name? If so then reference this answer from @Steve

Info@1minManager.com

1 Like
3

None of that is possible as mentioned in my original post “This formula is not evaluated in the context of a row, so column values are not available.”

You can’t query any values of the row, so no date comparisons etc, otherwise I would simply check the id of the task in the PM software, which at the time of creating doesn’t exist, so If it is blank then set the title to Submit New, if its not blank then set the title to update, however none of this is possible due to not being able to query the row.

Yes I am referring to the display name of the form in the title bar of the app and where it is displayed in the tab bar at the bottom.

1 Like
4

Please take a look at another workaround if it helps

  1. Create a copy of system generated form view of the table. So if the system generated form view is called “Bug Issue_Form”, keep the name this copied form as “Edit Bug Issue_Form” . The starting letter of this copied form name should be after the system generated form. In this example it is E against B.

  2. Create an action on the table of type “go to another within this app” with an expression something like LINKTOROW([Key Column], " “Edit Bug Issue_Form” ) Prominence of this action: Overlay

  3. Hide the system generated “Edit” action on this table. ( Prominence: Do not display)

  4. Insert the display name of “Bug Issue_Form” as whatever you want when record is added. Insert the display name of “Edit Bug Issue_Form” as whatever you want when record is edited.

There could be some variations depending on how your app is configured.

2 Likes
5

The alternative is to add a column of type Show at the top of the form that presents the desired text.

Is this a new row?/Does this row already exist?

2 Likes
6

I thought the display name of the form can’t relate to he data though? “This formula is not evaluated in the context of a row, so column values are not available.”

7

yeah I can do that as mentioned, however just looking to see if there was an easier way than duplicating most the views in my app between 2 and 5 times for each view

8

I didn’t suggest using Display name.

2 Likes
9

How does that change the title on the tab bar menu then?

10
It doesn’t
1 Like
11

Thats the objective, the only one thing I want to do here is set the text of the button on the tab bar menu

12

And what are you going to do if it’s not possible?
There are workarounds to get column values from context-agnostic places on our apps but you can’t do what you want in this case (because you need to get the context of your row)

1 Like
13

For now I wont do anything as there is no simple solution. In the long term once everything else is finished and I do finishing touches I could duplicate the forms, set the title of one form as New Bug / Issue, and the title of the other form to Update Bug / Issue, then link the new bug issue form to the tab bar menu, and link the update bug issue form to an action called from the tables and detail views. but thats just a lot more work and more maintenance, maintaining multiple views of the identical same data, if I want to add a row to the form I need to add it in both views, etc

For now ill just have to live with not being able to customise the title and the UI not being as intuitive as I want.

14

That’s a good idea.

Any time I’m stuck with something that would be solve using some workaround that makes me work more to maintain, I remember that with coding this could be harder :joy:

I mean, enjoy what AppSheet can do, even if a workaround is needed

3 Likes
15

Your life will be a lot easier if you choose not to fight AppSheet’s way of doing things.

3 Likes
16

I disagree with that, it’s not that I disagree with their way, I’m looking for smarter ways of doing things. I’m new to AppSheet and looking to learn therefore asking.

code readability is smart programming. As an example if I have a chunk of code 50 lines long, copying and pasting that chunk of code 5 times then changing one line of code in each chunk isn’t good practice. Instead I should move that chunk to be it’s own function and change that one line to take a variable input.

if I needed to change the code, the id have to update it 5 times, easy to miss one of the 5 and then I have a bug, as well as it takes time to update those 5 and keep them the same.

that’s exactly what I’m looking at doing here. One form reused multiple times.

or a great example of this is my other post from I think yesterday regarding the template variables. Other people told me the obvious answer if to not try and use template variables to tell if the row was added or changed, simply create extra bots and extra templates, one for added, one for changed.

if I took that advice and gave up trying, I would have over 20 templates, over 20 bots already with where I’m up to in implementing notifications. Currently I only have 4 bots and 4 templates which handle those 20+ situations, because those templates have multiple expressions for combinations of add, change and delete plus combinations with other data.

so in this case, it has taken some extra time to work out how to use an expression to know if a row was added, changed or deleted, but it’s saved me dev time by having 4 templates instead of over 20, and in future if I need to change those templates, which I have already needed to do, it’s just 4 to update and not 20+.

you’re clearly a smart guy so please don’t be offended by anything I’ve said, I respect you greatly and highly appreciate the help you give me and everyone else on here, I’m just explaining why in this situation I disagree and think the mindset of just do it their way isn’t the best. I think the greatest changes in life and the greatest evolutions in history have been because someone wanted to do something a different way, often when everyone told them it’s impossible and can’t be done, but they went against the thoughts of others and through determination worked out a way, which turned out to be amazing and make a big difference.

17

I always just use the Display Name “Add/Edit Ticket” in my forms.

For Detail Views, I am able to put expression using column values. I.e.: “Details for Ticket #:” & [TicketNo]

1 Like
18

The issue I have is I’m using the form for add and edit within various places in the app, and on the tab bar that form is used for add only. It’s good practice to have the ui as intuitive as possible.

therefore I want the title of the button on the tab bar to be add new bug as you cannot edit or view bugs here. When you tap on that button the form presents and auto prompts for the value of the first field. So if you tap the button thinking you’ll be able to view bugs, you realise you can’t, then have to cancel out of the select prompt for the first field, then tap cancel at the bottom of the form, then tap confirm you want to cancel. It’s 3 taps if you click into the form by mistake, that’s not a good ui experience.

19

What you though was a breakthrough idea to solve your problem was in fact doing the things the AppSheet way.

When we talk about that is to say that instead of fighting against the way the platform works accept the limitations and then you will be able to solve your problem on a creative but makeable way.

If you insist that something has to be done on a way that’s just not supported inside AppSheet, you are fighting against the platform.

All of this has nothing to do to beign open minded or just stick to some code of conduit when making our apps, it has to do to the fact that you can’t bend reality to make it fit your needs. People think they can and then they are surprised when it kicks back

2 Likes
20

Well said.