I’m using a complex find() to gather the place a note should be moved, based on a number of attributes. I have an action:
$Target = find(*the complex formula*)
and I was planning to use a stamp that sets $Container=$Target
The value of $Target is correct (i.e I’m finding the right path to my future container) but it’s quoted, hence If I stamp $Container = $Target, nothing happens.
I’m flumoxed …
I can’t replicate this. My test was to make an edict using a find() that matches a single other note (i.e. not this note) and sets $Target. The edict then sets $Container:
$Target=find($Name=="ee");
$Container=$Target;
My find() was deliberately simple. It proves the process worked but something else is having an effect. What is the ‘complex’ query used in your find?
I’ve uploaded a minimal example where It’s showing:
quote find test.tbx (99.5 KB)
My action:
$TargetContainer = find((!$IsAlias & $Path.contains("Test Classification") & $Language=="en" & $ISCOcode==$ContainerCode(that)));
The really weird point is the double brackets around the “search” function. I don’t get ANY results if I don’t have the (())
I’m testing:
. $Path.contains(“Test Classification”)
Note that this might be true for several different containers: /Examples/TestClassification and /Tests/TestClassification. That might not be what you want.
If you want one specific container, it’s simpler and a little more efficient to say
inside(/Tests/TestClassification)
or
descendedFrom(/Tests/TestClassification)
As a rule, it’s always good to be explicit about what is being negated. Include parentheses:
(!$IsAlias) & …
or
!($IsAlias & …)
Thanks for the tips. I’ll keep in mind - i did not know inside, for example.
But unfortunately I DO already find the right container, it’s just that find() returns a quoted string, which is useless to me : if I make $Container= $TargetContainer, TB will create a path name including the quotes
(obviously, once I get the path right, the stamp will read $Container(original)=$TargetContainer …)
Given your screen shot, I’ll wager the quotes are due to certain characters used in the note title (or the title of ancestor containers (i.e. in its path), that make Tinderbox choke other than for simple display.
Please post a small TBX file that replicates this problem. It only needs 2 notes, one with the ‘problem’ target name and one with the find() and $Text doesn’t matter—in case there are issues of confidentiality.
Aha. If you have a note named
Name: /TestClassification/031-Armed Forces
Then Tinderbox has got a headache. Does
. /minutes/May 31
mean “the note named “/minutes/May 31” or does it mean the notes named “May 31” which is inside the container “minutes”?
Tinderbox is doing its best here to say, “that really is the name of the note!” But (as you have seen) this way lies various flavors of inconvenience.
My suggestion: change all the “/” characters in your notes to something else. Colons, or hyphens, or spaces.
Similarly, if you’re going to do things like this, you don’t want semicolons in your note names. find() returns a set, and semicolons separate set elements. So, a semicolon in a note name is going to require similar special treatment.
Sorry @mwra and @eastgate for late reply to your help. Life, Viruses and Very Long Queues at the stores got in the way,
So it turns out the culprit was the parenthesis (brackets) at the end of the names. If I take them out, find() returns path without quotes.
I knew enough not to have semicolons and slashes in my names. Now I know I can’t have brackets/parentheses…
Thanks for the help, and the examples that allowed me to figure out my issue.
Cheers (and stay safe)
Glad that worked out, but I’ve made a note to experiment a bit to give better documentation if this edge case.
There is an additional workaround if you need (for whatever reason) to have troublesome characters in a $Name. I’d link, if I could remember where, so apologies for repetition. The solution is to make a user string attribute and use it to store the ‘real’ title, i.e. with troublesome characters; use a display expression to show this instead of the actual $Name which you can then ‘clean’ so that action code, etc. works correctly. Just be aware that if exporting, you need to remember to use the alternative title attribute you’ve made instead of $Name so you see the full correct title. It’s a bit of a chore, but it’s a workaround I’ve used in my research where many notes are the titles of papers (which invariably seem to include undesirable characters).
