I copied your search criteria into a new agent. This time there was no respons from the agent (just to make clear I have no actions defined for the agent, just the search string).
But, just clicking in the action area of agent popover, the search completed and the expected result was obtained.
I’m assuming the curly quotes is the forum software and not you, but if not, the .contains() argument must be in straight double quotes. Further we’re assuming in $type is a String type and not a List or Set. Note too that attribute names are case sensitive (and that general Tinderbox style is to name attributes with Caps or InterCaps. FWIW, I notice ‘type’ colours in the code box as if it is an action code operator so calling an attribute might be a poor choice. Using $Type seems safer than $type in that it avoids a possible parsing error.
Is ‘its parent’ the parent of the note being matched or the parent of the alias? The code sample suggests the latter but the text can be read either way.
When I use parent(agent) I get a fail and I’d guess it is because agent may not evaluate as a nested designator. Anyway, It is quite easy to solve. I made a stamp:
I missed the wrinkle with step 3, of describing the results of the divide and conquer. The search on type works just fine! I can post a demonstration file if that’s helpful, but I think we’re on the same page.
And Mark, your MyString workaround works perfectly for me. Thanks!
Oh, and I’m reasonable sure this used to work–this is a 10+ year old file that I pick up once or twice a year (last edit was ca. May 2022) so it may have been working in an older version.
Follow up question.
Is there an automatic correction when typing a query in the agent pop-over? I can have Tinderbox set to smart quotes and writing in the query field results in normal quotes.
If I write in $Text the smart quotes are there, as expected.
You’re very likely right, but things do change: not everything can keep working as it did, not that your code example looks dated! Action/query code has evolved a lot in the last ten years. Because the possible (parsing) outcomes were much fewer in the past, the syntax could be quite permissive in how the user indicated intent. With newer features there is a need to be a bit clearer. Very early code allowed:
Color = blue
whereas, though that might work now, the recommended style is:
$Color = "blue";
I don’t think $Type vs. $type was necessarily part of the problem. But, I’m a pragmatist and if $type was colour-hinted as action code and $Type as recognised attribute, I’d always go with the latter. Not making the parser ‘guess’ more than it has to is enlightened self interest.
I’d add one thing to @eastgate’s rubric above (which described what I’d done to make my earlier answer, and that is consider a test doc. Unless you’re already using a new/small TBX, step back and make a small test doc in which you follow the steps described. Trying to chase a code edge-case in a doc that already contains years of notes with all sorts of customisations and connections only adds to the challenge. Importantly, if the query/action work in the test doc and not in your mature doc, then you’ve further complicating factors you’ve not factored into the test. Note: don’t bulk copy from your big doc to the test, the whole idea is to flush the problem using mimal data/customisation.
Other reasons for getting in the habit of making a small test doc:
Over time you’ll find that the mere act of thinking through what’s needed for the test may well indicate the problem without you needing to complete the task.
Once the problem is resolved/fixed you can copy any new code you need but otherwise just delete the test doc to avoid cruft building up. If you’re tempted to keep the test doc for re-use, you’re missing the point if making a new doc for testing (don’t import unknowns); you likely aren’t saving future self any time.