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  as well as setting columns through relations that are formed as a result of a preceding step in the same compound action  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!