The app I am working on has Cards people can swipe through. The piece of the app I am working on now would allow users to create their own cards while using the app.
The natural place to put a + would be in the middle of the app in a Tab. BUT it seems that you cannot open a blank form in edit mode from a Tab (is this still true? is there a workaround with the same concept?)
Otherwise I would like a floating button in the swipe area - but this does appear to be a bug (when I copy the floating button ā¦ I then get 4 buttons!).
I also cannot add a button to the top of the screen to create a card.
Open to ideasā¦ otherwise prepared to have my dreams crushed
@Robert_Petittoās idea would be easiest. Just allow adding for that tab. But if you want to have a separate tab act as a form, you can do that by making your own custom form. Pick a sheet for the tab and set it to the details style layout. Then add your entry components and have them write to user specific columns. Finally add a submit button with a compound action that will write those user specific column values to whichever sheet you use for your cards. Then create a final action that clears out all of the user specific columns, so they are empty for the next time you come back to that screen. You could also add a navigate to tab action to navigate to your cards screen after adding the new record.
@Jeff_Hager very elegant solution! I had not thought about writing in and out of user specific columns. And @Robert_Petitto the + at the top works perfectly (and for some odd reason I had forgotten about that, being so used to making buttons). Thanks to both of you!
I ask because it hasnāt for me. In fact, it stopped working in two of my apps last month. Per Support, use of compound actions for the purpose of clearing USP values following a submission [1] as well as setting columns through relations that are formed as a result of a preceding step in the same compound action [2] is not possible/does not work. Solving this would require significant time and resources according to Glide engineers.
Iāve bumped into that. In my experience it works sometimes, but not all the time. Iāve long suspected that compound actions are prone to race conditions, and I asked the question a while back, but never got a response. Itās good to have a definitive statement on it from Glide - now we know what to expect, and can build accordingly.
Darren - Iāll have you know that clearing USP columns in this context has worked in the past hour which is driving me bonkers. Iāve had to instruct our team to halt a redesign. This shakiness has consequences. Iām not sure how definitive this answer is. In my view, something either works or doesnāt. If it works sometimes, it shouldnāt be available as a feature or capability.
I personally have never ran into any weird issues. I have an app thatās almost entirely driven off of one sheet (which is actually the user profile sheet). Different views are controlled by different visibility conditions controlled by user specific columns. In that app I have a custom form. To get to that form I have a floating button with a compound action. The first action just presets some default values in that same sheet. The next action is a āLink to Screenā āThis Itemā action. So the next screen it takes me to is still on the same user profile record.
Once Iām on the next screen, all entry components fill user specific columns in the user profile sheet. Since Iām already attached to that row, I donāt have to do anything through a relation. Also, I really donāt have to use user specific columns in this situation because each user profile row is unique to each user, but I just use them because itās easier to identify the temporary columns by the blue icon in the data editor.
Finally I have another floating button with a compound action that takes all those filled user specific columns, writes them to another sheet via the Add Row action, then I use a Set Column action to clear those user specific columns, and finally Go Back to the previous screen.
So far itās worked fine for me. The only time Iāve experimented with setting a column value through a relation is in my āAdvanced Multiple Row Reset Conceptā app. When adding a task in that app, I add a row, and then set a couple of column values through a relation. One column value is cleared and the other has a timestamp set. Both of those columns are user specific columns. From what I can tell, I havenāt had any problem there either.
You can find the advance app here:
This is the action when adding a new task.
Unrelated, but the only reason I clear a user specific column, in this case, is because I found a bug where an action on an inline list executed when a new row is added. The clear is just there to clear the value that was set when the inline list action was fired from the add row.
I went back and looked at your app (Iād been keeping a close eye) and saw some differences in our setups: I use a standard form, an on-submit action, and a third sheet.
The relation youāre setting the column through (Sheet āBlank,ā Rel-Task) is always on the first row. Thereās only one row in that sheet and one relation that changes based on USP input. The values set (Sheet āTasks,ā ParentID-Selected and Timestamp-selected) are on unique rows. Your USP entry components and relation are in sheet A, columns youāre setting are in Sheet B.
My user is submitting values from a sheet A, some of which are USP, to a sheet B where a relation forms on the fly to a sheet C. Sheet C is where the values I want to set are. Multiple submissions on sheet B can relate to one row on sheet C. In essence, the opposite of your appās setup. This may be part of the issue although it wasnāt pointed out.
Imagine a rel_ParentID column in your Task sheet relating sv-ParentID to ParentID (a non USP version of the column) in Blank sheet, and a regular Timestamp column in the same sheet. Every time a new task is submitted to Task sheet, my goal is to reset the timestamp column in the Blank sheet. A script can accomplish this butā¦
In terms of clearing USP columns, our application of it is very similar. Similarly, where this fails is when an on-submit action is used to clear those values. Otherwise, with the exception of some quirk Iām still ironing out, actions + setting USP columns has worked out quite well - Iāve used that extensively since your suggestion for setting default values and itās held up to some pretty twisted logic.
Yeah I donāt think Iāve ever tried to set a value through a relation on a newly added row. Iām not 100% convinced that the actions run out of order, but I could potentially see the issue here with all of the actions running very quickly and the set column action running before the relation can be computed on the new row. I have to wonder if, at the time that your row is added and the set column action executed, that maybe the relation is still empty on the back end and then canāt set a value through the relation since it hasnāt finished computing which row in the third sheet to match up to. It may be possible that it works sometimes, and other times it doesnāt work, all depending on how fast your particular device is to handle the processing and how much data it has to process through.
I have an app that is slow at times because it has a lot of data and a lot of relations from that data, so it takes a few seconds for my phone to initially process the data and run through all the computed columns before the tab loads. One peculiar thing Iāve noticed in my app is that I have one tab that uses a relation to get the latest date from a second sheet for a particular user, then I combine the date and user email in a template to get their latest records from a second relation to that same second sheet, which has a similar template. Initial load is slow, as itās probably processing all of the computed glide columns, but according to a rollup count I have on the screen, it also seems to initially pull back more records than it should (3000 vs. maybe 5 to 10 rows). My theory is that the template for the second relation is still missing a date from the first relation, so it only links up using the userās email and finds all the matches for that user. A couple of seconds later, I think the date updates in the template column and then it shows the correct count and pulls the correct rows into an inline list. Itās weird, so at most Iāve only been able to theorize what may be happening underneath.
I agree with @Darren_Murphy that it would be nice to have more of a high level programmers perspective of how all of these functions are processed, and in what order. I think if we understood how things work, then it would be easier to understand what works, what doesnāt work, why it doesnāt work, and how we can avoid any issues. Iām so used to being able to debug code as itās running, so itās a little frustrating when I canāt and can only make assumptions.
I had not realized that you could have branching so easily from Compound Actions. Superb news!
My use case:
my swipe app has different Card Types (e.g. Ask, News, Video, Training, etc)
there could be custom actions for both left and right swipes for each card type (e.g. if type = Training then show form to collect responses, then move to next card BUT if type = News then just record the swipe result)
By having this type of Compound Action split out, it will make my work on custom triggers so much easier. Great news!
