Agent - query - how to chain multiple attributes - OR?

[iPanini (Erwin Panen)]

Hi, I’ve done quite some searching but can’t seem to find an example simple enough..
As I’m working to better understand how to use Agents, I’d just like to use two conditions with either / or (and is also allowed).

I’m using an attribute “atbref”.
I also use “atbref” in $Name.
If I use ($Tags==”atbref”); I correctly get all notes with $Tags==”atbref”
If I use ($Name.contains”atbref”) => I correctly get all notes from which $Name contains “atbref”

But how do I just chain these two conditions?
I’ve done some trials with OR and also with | but these don’t seem to work the way expected..

I’m aware of the existence of “DisplayExpression”
Further down the line, I would like to be able to e.g. find / locate items with multiple ways of spelling (or misspelling for that matter), but I would also like to learn how e.g. to strip parts from $Name and put these in their own rightful “attribute” etc.

Thanks for helping out!

[mwra (Mark Anderson)]

As you’re using aTbRef, have you found the action operators: the query logical AND join, the query logical OR join? See more on query syntax.

There is no way to ‘chain’ queries, which in Tinderbox would imply a ‘dot’ connector. Queries are written in action code but used logical operators. Thus, to join multiple discrete query term you use either an ‘and’ (&) or ‘or’ (|) operator. Using database style AND, OR and NOT will not work.

Either/both join types can be used if you have more than two sub-queries. Queries are parsed (understood by the app) read left-to-right. As with a spreadsheet formula you can affect the order in which sub-parts of the overall query are read by using parentheses to control parsing order; see Conditional statements using multiple arguments.

Don’t forget to try aTbRef search if you haven’t already. It is a ‘fuzzy’ search so improves on 1980s-style database keyword match for search.

[iPanini (Erwin Panen)]

I’m clearly running in circles..
Before posting, I thought I was close, meaning, I had two query’s that, at least so I thought, did what they were supposed to do, and was then stuck at chaining these two query’s toghether. And I could not get that to work. But…

Here are the two query’s:

1. $Tags==”atbref”; That one works for sure.
   Question: What if I want to expand this one to “find” a larger scope, meaning take into account various ways of spelling, small caps, large caps? How to find either atbref and or aTbRef?

2. $Name.contains”atbref”;
   I thought that this one was working, but clearly it isn’t. I’ve been experimenting amongst others with the | symbol (pipe), but I guess I was mistaken. I verified using $ChildCount which resulted in 3048 Children (the inspector says I have 3045 Notes, not sure from where the difference..)
   My expectance is that it should find some 25 notes, but instead I think it show ALL notes in the file as a result.
   So the question is then: How do I formulate the query correctly to list the 25 notes that have atbref in the NoteName ($Name)?

3. Which brings me to question number 3:
   Where can I find detailed working description of the find-bar (what is the correct name?) in the View pane?
   I could not easily find this in atbref, clearly if correctly used this can and will help a lot.. But apparently I’m not there yet..

   

Thanks for helping out!

[mwra (Mark Anderson)]

See the == equality check for why $Tags=="atbref" doesn’t match other case variants. Note in that article the section explaining why == works differently with multi-value attributes: $Tags is a Set type attribute.

@iPanini

$Name.contains”atbref”

Invalid syntax. See String.contains(regexStr), note you’ve omitted the necessary parentheses enclosing the operator’s argument. Actually I’d suggest you likely want String.icontains(regexStr) if you want a case-insensitive match.

@iPanini

I could not easily find this in atbref,

This: Find toolbar (view pane)?

Did you try the Search page in aTbRef:

Note that the view pane and text pane both have Find bars but they work slightly differently.

[mwra (Mark Anderson)]

Odd, the forum submitted my post unasked. To continue…

@iPanini

then stuck at chaining these two query’s toghether

I repeat, you can’t chain queries, in the way you can dot-operators in an action. You need to use & and | logical joins. I’m not trying to be pedantic: using the terminology the app uses makes it easier to search the available support materials. For instance if you search aTbRef for ‘chain query’ you will get some results but they don’t relate to joining queries. Search for ‘join query’, and the and/or join articles are the two top matches.

In the same way the documented syntax matters. This is wrong:

$Name.contains"atbref";

Tinderbox will try to guess what you mean but, as you’ve found the results are not as expected.

Note: although written in action code syntax, queries never use teminating semicolons, even for a single query. If going multiple queries, joining operators must be used.

Also, when quoting arguments (e.g. the ‘atbref’ in .contains("atbref"), always use 'straight 'quotes. Here you likely did that but annoyingly the forum software auto-changes them to typographic ‘curly’ quotes. So I note this issue out of caution as a thing to check until you are more confident with action code syntax.

Using the correct syntax, Tinderbox can understand this:

$Name.contains("atbref")

[iPanini (Erwin Panen)]

In the mean time I’ve adapted the query to:
$Name.contains(“aTbRef”);
That at least works, but it only throws 18 results. ($ChildCount => 18)

@mwra

Did you try the Search page in aTbRef:

Yes, I did, at least I went the other way round, searching for cmd + F, as I knew that makes the Find toolbar appear, but I guess the “Fuzzy” logic went astray

No, seriously, thanks for helping out.. Makes me dream about “a pint of Guiness”..
I’ll try to go more indepth with the Find toolbar, but for now, could you help me understand why the Find toolbar will show 22, and the agent 18?

results, and the why the $Name.contains(“aTbRef”) results in only 18?

Also the following happened (at least I think):
As I was testing putting in the missing brackets in the query, I tested both .contains and .icontains.
Without realizing what happened, a few minutes later, I noticed that I had now a second “aCollectaTbRef”. As I did not immediately realize, I at first thought this was due to me using some erroneous keyb shortcut combo, so I selected the twin, and checked for $IsAgent which was not checked, at which point, I pressed delete.
Could this be the result of alternating from .contains to .icontains?

(Desperately needs Guiness )
Thanks for helping out!

I am now also aware of there being a difference between $Name.contains and $Name.icontains, will try to study that later.

[mwra (Mark Anderson)]

Searching for Cmd+F would logically find you a page describing a page that calls a Find, such as a the Edit ▸ Find menu. Actually, Cmd+F is unintentionally ambiguous as what it opens depends on whether the View Pane Find or the Text pane Find is opened. I’ve added 2 new links the Find menu page for the next aTbRef refresh. But, even if counter-intuive, search for what’s actually wanted is a better search start here.

So your agent searches only against $Name, i.e. note titles.

By default, the View pane Find toolbar (view pane) has a preset scope/comparison type. The documentation states::

By default only Text and Name are pre-selected.

So your view pane Find searches Title ($Name) and Text ($Text). In the current v11.6.0, that search is a case-insensitive string match (you can check by clicking the chevron in the search input box and checking the pop-up menu).

So, if the agent and the Find are doing different searches, then this would explain the different results.

I’ve a hunch that if you go to the view find bar and click the Text control so it isn’t highlighted, the find result will fall to 18.

I’ve been a bit slow here. Noting some German in your screen grabs, language may be a factor here. If so, mu apologies as everything is harder is having to translate the instructions. From v11.5.0, is using French of German there are localised versions of menus (see here). Also all aTbRef pages have a Google translate widget that may help. I’ve had reports that the results vary unpredictably from useful to Monty Python-esque “My hovercraft is full of eels” gibberish output. Translating technical writing tends to falter if the (now AI) doesn’t have a reference list of terms to differentiate the app’s meaning away from other meanings of words.

I’ve another tip for this stage of learning. Don’t use you main documents. Instead make a new TBX with a minimum number of notes/attribute values so you have a much more exact knowledge of the number of matches to expect. You don’t need more than a few values and so different case examples. It is now easier to tell if the result is wrong operator/syntax or because the operator doesn’t work in the way we might assume does (there the documentation helps—hopefully!)

Start by testing single value attribute types (like string and number) and only move only must-value types (list, set) once you feel single value searches are working as you expect. Now, once done, you can put searches (Find, agents, etc.) into your working doc and have more confidence in the result.

Using small test documents this way, testing one aspect of the app at a time with no conflicting content, is a learning super-power.

[iPanini (Erwin Panen)]

Thanks!
Not sure what happened before, maybe a forum glitch, no problems.
To clarify: English language is / should not be a problem. I’m doing a lot of research on the matter of PV (PhotoVoltaic) and heat pumps, and there’s a lot of good stuff to be found on German youtube channels, also, language wise, neither French nor German are an issue for me.
But I’m working on ways to collect the youtube transcript and convert those to usable text. (As you undoubtedly noticed

As for the above in this thread: I should have been more specific too, All is related to the View pane, not the Text pane. But indeed you very correctly so, draw the attention to the mix of $Name and $Text!!

I also thought of doing some smallish testing in another small file, but as I was so drawn into this, one even forgets to focus out and take some distance.
I’ve also been thinking on ways to incorporate multiple languages in a TBX file..
The closest I’ve come is to think about the book analogy: have a ToC in front and an Index in the back, then cross reference, but that doesn’t solve everything..