Usually, when using a choice component, I know exactly where the values will go: it’s either the desired row if I refer to it, or it’s the first row if no relationship is assigned.
Today, however, Choice surprised me. In my new application, he contributes the value to the last line. It doesn’t suit me at all.
There was a similar question here, however, there was no clear answer.
The only thing I didn’t do as always was on the Tab I used the Details style and then on the Inline List I used the Choice. In my opinion it shouldn’t matter.
Any ideas why this is happening?
The choice component should always write a value to a column in the current row.
Which row that is will depend on how you got to the current details view, and whether or not you have any filters or row owners in play.
So I don’t think we can give a definitive answer to your question without a bit more information.
When you say…
Can you expand on this please?
Do you mean that the Inline List has a Show Details for this item action, and then your choice component is on the details screen for each list item?
If that’s the case, then the row that gets written to will correspond to the list item that is selected.
If that’s not how you have it set up, then you’ll need to explain more.
Adding to this, a top-level details screen with sort would also contribute to this behaviour.
No, I didn’t mean it.
What I mean is that when I go to the “Платежи” (Payments) Tab, the Choice component can’t know which row I need because I’m using the Details style. Usually in this situation (when row is not defined), Choice puts the value on the first row. But not at this time. That’s why I can’t understand why.
Once again: I go to the Tab and without doing anything I immediately use Choice. Choice simply cannot know in any way in what row it is necessary to add value.
No sorts or filters are used
No, I mean the tab level. Do you have any settings for sort or filter?
The Inline List uses the data selected in Choice to filter the desired values.
But it’s a simple check If-Then-Else. Neither the Source for Choice nor the Data is affected.
A Details screen at the tab level most definitely knows which row it is connected to. I think you still have not checked any filters or sorting at the tab level. We are not taking about filters or sorting for your inline list or the choice component. We need to know the settings for your detail screen. You have full control over which row that screen is connected to. It only defaults to the first row if you have not set row owners, filters, or sorting of any kind. But you need to check the tab’s settings instead of the component settings.
A detail screen is always attached to a specific row. If it wasn’t then all entry components would be grayed out and you would be unable to edit them.
Really! I created this Tab by copying another and did not remove the sorting that was on the old sheet.
Now that I’ve done this, the values are being added to the first row as they should be!
This is a great experience for me.
It would not hurt to specify such things in the Documentation…
Thank you so much for your persistence!
Glad you have it sorted (pun intended)!
Thank you very much for your help and responsiveness.
But all this time I knew that something was not working right and did not calm down until I found the answer.
So I’m good too
Glad you got it figured out. Typically, if I’m doing any sort of screen that requires an on screen choice component, I’ll build the screen off of the users sheet so then that way the choice component will always point to the signed in user’s row which can be referenced anywhere in the data editor.
Do you mean use the user profile? What advantages can this give if I just need to insert the right value into the right line? I think it’s handy if Choice works on one Tab and its values are used on another.
Yep. The advantage is that you can create columns in the user profile sheet that allow the user to store values as “global variables” that can be referenced anywhere in the app. If I’m building a new tab that’s going to have a details view off the bat, i typically base it off of the user profiles table and then just add inline lists of other tables and filter them based on the user profile columns accordingly
A very interesting approach. Thanks for the good idea. Next time I will try to apply this knowledge.
If only we also had global write to user profiles…