Using List.icontains("pattern")

I need some help understanding how to use List.icontains(“pattern”)

I’m looking at Michael Beckers excellent video Working with Lookups, Link Actions, and Automated Links in which there is an agent the query for which includes

$Character.icontains($Character(agent))

This appears to be almost self referential in that the list ($Character) is being scanned for what appears to be the list ($Character). Clearly that’s not the case. The “pattern” appears to be qualified by the addition of (agent) but in searching around I don’t see any reference to this type of qualification or how it works.

Any pointers to where to find a reference would be appreciated.

Thanks.

The query here unpacks as: "does the string in attribute Character march wholly or in part, case insensitively, the value of the attribute Character as stored in the agent.

This trick makes it a simple as showing the attribute Character as a Displayed Attribute in the agent. Now, every time you edit $Character ( the value of attribute Character) in the agent, the query changes.

Does that help?

Thanks.

I’m getting there but I wonder why the term “agent” is necessary, does it have some function.

Based on your explanation my pedestrian understanding is:

The query looks at the value in the character attribute of the agent and searches other notes in the Character attribute for a matching value. Since this is a query associated with the agent I’m wondering why the apparent “qualification” of agent is needed. On the surface it would appear to be unnecessary.

I ask because I always find Tinderbox very unforgiving and so it helps to know exactly what needs to be specified.

When you refer to an attribute’s value (e.g. $Width), you implicitly are asking about the value for this note, $Width(this).

In an agent query, this is bound to the note being examined. If an agent is looking for notes that have $Width>10, it examines each note in turn and asks, “It this note wider than 10 map units?”

But sometimes, a query needs to compare each note to a value stored in a specific note. For example, we could look for notes where $Width>$Width(/Example) – all the notes that are wider than the Example note.

In Michael Becker’s example, he wants to examine the value of $Characters, looking for a specific character that is stored as the value of $Characters in the agent. Just as this designates "the note we’re examining, agent means "the agent whose query we’re evaluating.

It is an action code designator: see here.

As @eastgate has suggested it is a method of saying, for attributes, “give me the value of attribute named X, but for note ‘XYZ’ rather than the note I’m currently assessing.” In a wider sense it allows action code and export code to address predictable targets like “my children” or “my child number N” without having to write a more bespoke query. Consider, the item ‘C’ under path A/B/C in the outline (the canonical source form of a Tinderbox document band as see in Tinderbox’s outline view) is not the same as article C' at path A/B/D/E/C`.