Re: 2 quick things about INPUT()

Marc_Dillon · 05-02-2022 02:27 PM

I just discovered that you can use a Grouped Action, where the first action displays a pop-up INPUT dialog to accept input, and the second action navigates to a view based on that input. That was a pleasant surprise, I was not expecting it to work, since it is sort of like 2 navigation actions in a row.
ResetOnEdit does not appear to work with the INPUT() pop-up dialog box. This one is the opposite, something that I fully expected to work, but does not. Can't win 'em all.

SkrOYC

Thanks for the inputs (pun intended)

dbaum

Yes, thanks for sharing this. If possible, please elaborate or share an example of #1. I'm also using INPUT() in some grouped actions. In my current implementation, the input is simply tied to an enumlist column that simply holds its data temporarily--the grouped action elicits the input to populate that column, then performs another action to either add or subtract the temporary column's list from the main enumlist column that holds a list for reference throughout the app. I wonder whether there's a way to accomplish my need without the temporary column.

Also, does INPUT() work reliably for you? I encounter problems.

Marc_Dillon

Example:

INPUT Action is on parent table, for column [input_search]
Child table has the records to search. In this case there can be many dozens of child records, differentiated by a 10+ digit code. Manually searching is impractical, especially as the code can be scanned.
Grouped Action runs a LINKTOROW(ANY(FILTER())) based on the INPUT'd [input_search] value.

>>"Also, does INPUT() work reliably for you?"

When you use it correctly/within-its-constrains it does.

Joseph_Seddik

And I'd like to add:

3. INPUT() does not seem to work within a SELECT() statement. For example:

FILTER(table, [column] = INPUT(handler, ""))

dbaum

I initially tried something like that too. Then, I found in the help article an explicit explanation that INPUT() is only supported as the top-level function in an expression.

Joseph_Seddik

Thank you!

I couldn't see this, would you please point me towards this part? 🙏

dbaum

Following is what I was recalling from the Dynamic inputs for data change actions article. Maybe the specification of "in a data change action" means that INPUT() won't have to be the top-level function in the other targeted future usage scenarios cited at the end of the article.

In a Data Change Action that sets the value of a column, the INPUT function must be used as the top-level expression

Joseph_Seddik

@dbaum Thanks my friend!

dbaum

FYI, per our other discussion about INPUT() I've been testing different scenarios. The INPUT() function does seem to work reliably within the LIST function, as in the following example, even though it's not the top-level expression.

[Attendees] - LIST(INPUT("UserToRemove", ""))

Joseph_Seddik

Yes, it does, but as I understand it, this is the top level 🙂 I understand levels as contexts. The current table comprising the context for all of its expressions is the top level. SELECT() operates on another context, which in this case would be a sub-level relative to the current table. I might be wrong.

dbaum

Ahh, that makes sense. I had interpreted "top level" as the outermost level of nested functions within an expression--not the current table invoking the function as opposed to other tables referenced within the expression. One more opportunity for clarification in AppSheet documentation....

Joseph_Seddik

I agree, this is only my attempt to make sense out of the documentations 🙂

Did you see the [_ThisRow-1] part? It is written in Middle-Earth Elven 😁

dbaum

That makes me feel better. My observation is that you're perhaps the most multilingual contributor in the community, and if you have difficulty understanding some of the help articles I'm somewhat relieved that I can't follow them either.

Steve

@Joseph_Seddik wrote:
Did you see the [_ThisRow-1] part? It is written in Middle-Earth Elven 😁

To what does this refer? Which part?

Joseph_Seddik

Thank you @Steve !

This part, in this article: Template Start Expressions | AppSheet Help Center. I could only make my template work through trial and error, and at the end I couldn't reconcile what I did with the doc so that together they make sense.

Steve

Yeah, it took me a log time and some experimentation to understand that mess. It really all comes down to this:

https://www.googlecloudcommunity.com/gc/Tips-Tricks/FAQ-FILTER-LOOKUP-MAXROW-MINROW-REF-ROWS-and-SEL...

Joseph_Seddik

Wow! Thanks @Steve this is awesome! Unfortunately I didn't notice this part before in the comments. I guess the concept that [_ThisRow] being a shortcut to the topmost level from any lower level was what evaded me. Very informative graph and excellent explanation as always. If it was up to me, I'd just ditch the whole AppSheet documentation and replace them with your community posts, unless you were the author. Seriously :).

I'll study your whole post again in detail.

One question please, so in a template we can treat a <<start:>>/<<end>> as a level as if it were a SELECT() statement, with this my now-working-after-experimentation expressions in the template would finally make sense. Is my conclusion correct please? Thank you!

Steve

Yes. The template itself is _THISROW. <<Start>>/<<End>> is equivalent to a query.

Joseph_Seddik

Couldn't be clearer! Much appreciated @Steve