Has anyone figured out the conditions that prompt the app to auto-fill the parent link when adding a row from an inline table?
What you mean with …prompt the app… @Steve? Like a bubble for example or you mean some kinda auto-focus?
When I click the Add link/button in an inline table:
In some cases, the form that opens will have an appropriate column pre-filled with a Ref back to the row I hit Add from; in other cases, no column is pre-filled. I can’t figure out why some auto-fill and some don’t.
As per my experience; it directly fills the Ref value if there’s a reverse-reference (isPartOf) but it does not if there’s a direct reference. When there’s a direct reference, I generally use a de-ref in the initial value of the ref column of the child table to recall the key column value of the parent.
After some experimentation, I’ve found that if REF_ROWS() is the entirety of the column’s App formula expression, the Add button in the related inline view will auto-fill the column referenced in the REF_ROWS() expression in the new row. To retain this magic, the REF_ROWS() results cannot be modified in any way, such as by list addition or subtraction, or with SORT() or ORDERBY().
REF_ROWS(...) + LIST(...)
REF_ROWS(...) - LIST(...)
IsPartOf, ON or OFF, appears to have no impact.
If you imagine an add-row operation is equivalent to an action of type App: link to another view within this app with a Target expression of
LINKTOVIEW("form-view"), the magic REF_ROWS() expression appears to change the Target expression to
LINKTOFORM("form-view", "parent-ref-column", [_THISROW]) (where
parent-ref-column is the column named in the REF_ROWS() expression).
Sorry for being so dumb, but I couldn’t quite get why the ref column value is not auto-filled in the case of a direct reference but auto-filled in case of a reverse-reference on the contrary. Appreciate provided you can clarify the solution a bit more @Steve. Thnx.
I don’t know why, unfortunately. It’s just my observation. I think AppSheet recognizes a REF_ROWS() expression and treats in in a special way.
This is great info, @Steve! Thanks for testing and providing your results.
Could we get this added to the REF_ROWS() doc?
@Steve I’m not 100% sure, but I think I have found the other work around to keeping the magical effect. I have an EnumList of base Ref (mostly for back-end editing), and then a a VC of List base Ref with an AppFormula pointing to the EnumList (for front end inline display). Unless I’m forgetting about something else I did, I believe it keeps the automatic population.
This was working, despite the presence of Orderby(), for months in an app I have. It stopped working today and reverted back to this (I guess intended) behavior.
I have no explanation for any such change in behavior.
Very likely it was a bug… and it’s been squeaking by because no one would think that behavior is a bug.
But if the intended behavior is for the “Magic” to only work when you’ve got the system-standard Ref_Rows() - this is very limiting for data-schema design capabilities.
I’ll have to manage the standard-system inline view (so I can keep the magic), but I’ll have to create copies I may need (with OrderBy() and such) for calculation purposes - duplicating data.