Hi everyone
I am experiencing an issue with data entry in my app where subsequent submissions are incorrectly populating the first row instead of creating new rows. Here’s a summary of the process I’ve set up:
-
Instead of using the Collection component, I’ve implemented a custom form using a Text Entry component and a Button. This allows for live input directly into a data-table.
-
On the app’s main page, I’ve placed a container with a text field and a button.
The button is configured with the following actions:
User interaction > Add row > Show new screen (Data: This item, Target: Current)
The first item is added correctly with empty entry fields
But when adding a 2nd item, a new row is created and that’s cool but the data is entered into the first row rather than the new row.
What’s wrong in the process?
Is there a reason you opted to create a custom form instead of using a native form or a form container? A custom form (not an official glide feature) is just entry components on a detail screen linked to an existing row in the table, so you are just updating live records in real time and then using them to create new records.
Well, I opted for live records because it allows me to dynamically manage the visibility of emerging extra components in real-time. Here’s what this means in practice: My platform is a marketplace for construction materials. Each product has a category, like “Structural elements”(Category) for Columns (Product).
I prompt users to first select a category to avoid overwhelming them with too many products. For them to receive a relevant set of products, the table needs to have a record of the chosen category already.
1 The user selects a category.
2 This category is immediately recorded in the table.
3 Right after selecting the category, the user is presented with the option to choose components relevant to that category.
This can be done using visibility conditions based on the “screen” value that you have chosen as the category, in a native form.
Things get a bit hard if users change the category mid-way since if they write something to elements that don’t belong to the new category, it’s still there, but you can address this with a combo of wait action (for 2-3 seconds) and then set column to clear the columns that don’t belong to the category.
1 Like
That is clear now. If you want to stick with a custom form, I suggest creating a separate table with user specific column to act as the driver for your form. But still have it add rows to the existing table.
Thanks Jeff and ThinhDinh
Maybe I misunderstood your advices but what I don’t get is that the Glide “Collection” form just add rows to the data-table as it needed and that’s it - everything works fine. But when it’s a custom form, the data is overwritten on the very first row of the data-table, rather than being added to a new, just created by this Custom form, row.
That’s the whole question - why the custom form writes data into the first row and not to the newly created row.
Because your screen is most likely attached to the first row in the table. This is one reason why Jeff suggested the following:
1 Like
Thank you Darren. While I understand the suggestion to create a separate table with a user-specific column to drive the form, it doesn’t seem like an elegant solution to me. I mean creating an extra table for each specific function on the site seems bit like a crutch?
I’ve come up with an alternative: I noticed that unlike the custom form, Glide’s- Collection-new-item-adding-form handles row creation properly and creates a new row. So, I modified this mechanism for creating a new item in the table by adding 2 steps. THe first step is to use Glide adding tool power of adding data into the right row, the second step is to write the necessary parameters in real time. Here’s how it looks.
Is there any cost to this approach, do you think? For me the only disappointment is that I can’t rename the “first” screen buttons 
Custom forms are essentially a hack created by us users to get around some limitations with native forms, such as being able to use computed columns. It’s not ideal, but it gets the job done.
This would be no different than using a native form opened from a button, or a Form Container directly on a detail screen.
That depends on which plan you are on now. With plans prior to last week’s plan changes, yes updates would count when not using native forms because you are updating data in the table in real time as you update each value (native forms don’t do that because nothing is written to the table until you click on submit). So depending how how quickly your users go through the form, you could include one or more additional updates. That was the downside of doing anything outside of a native form. Now with new plans, updates don’t count against Glide tables. It all depends on the plan you are on now. So to answer your question…depends…
