Can you change behaviour of the "Row selected" event in an inline view based on from which "parent" view you entered that view?

I understand if the title is a bit confusing. The scenario is like this:

You have two tables, A and B, in an app/sheet which both contains entries. To establish a many-to-many relationship between these entries (could be foods in one table and food categories in another, just as an example), you create a table C that consists of rows with one entry from table A and one entry from table B. In AppSheet, this would automatically generate an embedded view of table C if you navigate into an entry of table A or B (using a simple REF_ROWS(Table C, table {A, B}) function).

This is great and works as expected. The issue is, if you are in an entry of say table A, and navigate down to the embedded view of table C, and click on one of the entries, it will take you into a detailed view of that entry in table C, showing a ref to the entry in table A and the entry in table B. But if you wanted to get straight to the entry in table B, which this entry in table C โ€œpoints toโ€, then that is an extra (annoying) click.
Now, this can be changed, but as far as I can see, only one-way. If I find the system generated inline view of table C and scroll down to behaviour, I can change the โ€œRow selectedโ€ event action from:
**auto**
To:
View Ref(<table B column>).

This will then take me directly to the entry of table B when a row from table C is selected. This is exactly what I want.

Unfortunately, if I then navigate into an entry of table B, scroll down to the embedded view of table C and select an entry I also get redirected to the entry of table B (which I just came from). Of course, this makes sense, since I just told AppSheet to do exactly that, but the behaviour I wanted is, that when I click an entry of table C from table B it should take me to the entry of table A (and vice versa, as described above). Is this possible? It doesnโ€™t seem like I can create two of these views and then use one of them for one table and the other for the other table, since theyโ€™re just embedded versions of the views generated for table C.

I hope this makes sense, and thanks in advance!

Best regards
Viktor

Solved Solved
0 5 240
1 ACCEPTED SOLUTION

5 REPLIES 5

Steve
Platinum 4
Platinum 4

Thanks for this. It does sound like something alongside what I need, but in my example, in both cases I will be in the same view (and table) so Iโ€™m not sure this is powerful enough. Unless there is some solution Iโ€™m not seeing?

@Steve Do you know if CONTEXT() is able to access the view that was just before the current view?

It cannot.

I see. Unfortunate, but thanks for the answer!

Top Labels in this Space