Different view for add vs edit

Hi,

First time poster and recent addition to AppSheet here. I’ve searched this forum and looked at sample apps, but I think that not knowing the proper terminology is what is keeping me from finding a solution. I’m sure that what I’m trying to do is trivial.

Setup:
I have a Request_Form used to add/edit new rows. For simplicity, let’s assume that only one column, called Work, must be input by the user.
I also have a static read-only table, Options. Options has columns, one for each list of possible answers to the Work column in Request_Form, based on whether this new row is being added (for the first time) or edited (and was already existing).
Request_Form correctly pulls in and presents the various Options for Work as a ref.

Question:
How to a create a new view, such as a Requests_Form when adding a new row vs when editing a previously existing row?

Use Case:
How do I have some buttons/choices (a ref to Options) when adding a new row, but different ones when editing a row (after it has already been added)?

I would like to have, when adding, only the choices “Yes” and “No”, but when editing, I would like to have the options “Yes”, “No” and “Completed”. This would permit someone to edit Work to show that it has been “Completed” and that the Work is no longer pending.

Alternate Question:
Perhaps I shouldn’t be editing the Work column in Requests. Perhaps I should be creating a new row in a different table (perhaps using the same uniqueid()/key) to indicate that the Work has been “Completed”.

Thanks in advance for any assistance or insight you can provide.
SJL

Welcome! :slight_smile:

The choices you present to the user will be determined by expressions within the columns of the form. The question is: how do those expressions determine the row is a new addition, or a preexisting row?

You could create separate views for adding-new and editing-existing, then have your expressions consider the view being displayed to decide which choices to offer, I’m not fond of this approach (generally) because the column behavior is dependent on the view, so I have to present the row in a particular way to get the desired column behavior. Myself, I prefer to keep the logic and the presentation as separate as possible.

My preference in cases like this is to use expressions that examine the actual state of the row: does the row already exist? If not, it’s a new row.

The data in a form view is saved to the table only when the user clicks the Save button. Until then, that form data is only visible to that row itself (its expressions, mostly). When an existing row is edited, its data is copied into the form, and the form works with the copy until the form is saved. When a new row is edited in a form, there is no existing row to copy, and the new row won’t exist in the table at all until the form is saved. Key points: a new row doesn’t exist in the table until the form is saved, but an existing row does.

The SELECT() function and its derivatives (FILTER(), LOOKUP(), MAXROW(), and MINROW()) all examine tables directly, and ignore row data in a form. This means these functions can be used in expressions to determine if the row in the form exists in the table. The following asks, “does this row already exist in the table?”:

ISNOTBLANK(
  FILTER(
    "My Table",
    ([_THISROW].[_ROWNUMBER] = [_ROWNUMBER])
  )
)

See also:




3 Likes

Very lucid explanation on new and existing row @Steve

2 Likes

Hi Steve,

Firstly, you went above and beyond with your explanation. I few pointers to the functions would have been ample assistance. Much appreciated.

I, too, try to keep UI separate from data as much as possible. The reference to the current (unsaved, not yet in a table) data is what I did not know how to access. This solved it for me.

For the benefit of others, here is what I did in a Valid If check:

IF(
  ISNOTBLANK(
    FILTER("Requests", ([_THISROW].[_ROWNUMBER] = [_ROWNUMBER]))
  ),
  Boolean Requests[Request Options],
  Boolean Requests[Request Options] - Boolean Requests[Invalid New Options]
)

“Requests” is the data, to/from which we are adding/modifying rows.
“Boolean Requests” is another table, which includes lists of valid (in the column “Request Options”) and invalid (in the column “Invalid New Options”) options based on some criteria specific to the app and its data.

Hope this can help someone else.
SJL

3 Likes