Never occurred to me to add those sv->whole row columns to the User Profile table, but it’s so obvious when you say it. I’ve been in the habit of adding one to every table where I need to use it. Time to change habits
Likewise. Didn’t cross my mind to use the user table.
I’m already in the single row table (tab source table) when I trigger Add mode in my custom form. I only needed a single value → Whole Row when I open the custom form in Edit mode. So I guess I didn’t waste too much time. But good to know if I need to call the form from more places.
I do have a single record “control file” which contains various information used elsewhere.
As always, I seem to push the limits of Glide. I tried “whole row”, but unfortunately, the new field does not appear everywhere i’d used the individual fields. In a custom action, I cannot set the column value using that field. It doesn’t show up.
As long as the source sheet for the screen is the one that has the single value, it should work. Again, life will be easier if the single value → whole row is in the user’s table:
Looks like Control is referencing a whole row. If you want to use a column from that row in an action, you’d need a lookup on top of it to fetch the column value. Bob mentions that in his video.
I think what Bob just said about selecting values from relations is the issue – because in my “add row” action, I don’t even see it as a relation, and it does not show up when I select “User Profile”:
Just to chime in. I use a custom form because I have a particular use case.
With one of my choice components, I need to write both the visible description of the choice, as well and the underlying number. So in my example below, I need to save both the Lesson Length Name as well as the rate that’s associated with that Lesson Length. For me lesson rates can change in the future, so to avoid affecting older lessons when rates change, I can’t use relations to pull in a rate based on length.
I use that underlying number as part of a live calculation. This is so the user can verify in real time if everything is correct before clicking on submit. Each user can have different rates, and rates can differ per user, so everything needs to be dynamic.
So in my case, a custom form is the only viable option, since I can’t achieve the same functionality with a native form. It also allows for some more robust validation before allowing the user to submit a form.
Fortunately for me, this app has about 1.5 users, so going over usage limits is not a big concern, but I understand where it can be something to consider. There are use cases for custom forms, but if they can be avoided, I do agree that a native form is the way to go.