just a small one - took me some time to debug my code because of this:
var:string myCurrentNote = $Path(this);
If the note title contains a slash like in “I am just a/poor title” working with $Path will get you into trouble. Since $Path returns the path unencoded the “/” will break the following code if you try to address a specific note using this value.
Yes, this is a known problem—see here. The general solution, especially if using a lot of action code is to use $IDString (previously $ID) instead of $Path or $Name.
The main place this bites is using linking/unlinking action operators, e.g. linkTo(), with path ($Path) info.
For those who (need to) use slashes or parentheses in note names—or non-unique note titles—at present best practice is to use $IDString or $ID instead of $Name or $Path in code
Thanks!
If I pass “this” to a function:
myResult = aFunctionName(this);
can I compare the the passed value like in:
aFunctionName(theNote) {
if($IDString != theNote) {...};
}
and what Do I do if I use the find() operator or other internal function that return $Path type results?
I have to use collect_if ?!
I’m not 1005 sure of the context here but $IDString is a string-type attribute. However most designators, I believe, pass $Path info by default. Regardless, your issue is easily fixed like so:
myResult = aFunctionName($IDString(this));
aFunctionName(theNoteIDString) {
if($IDString != theNoteIDString) {...};
}
Note that is where $IDString is better than $ID as the latter is number type and untyped function arguments are received in-function as a string. $IDString resolves this as it is already a string and doesn’t coerce into a number (unlike $ID).
I don’t see designator changing their default resolved data, as for most trivial/novice use $Path (or $Name as a proxy of $Path) is easier to use and rarely is problematic. It is deeper use of the app where ‘problematic’ paths occur and use of $IDString makes more sense.
Thanks a lot for your fast help.
Comparing $IDString with this works by the way 
I think we should avoid using $Path until it has been fixed. If the user is allowed to enter a “/” then there is a big chance that it will break your code.
$Path should return something like
"/first level/second level/the name\/of a note"
I will remove $Path from my code completely.
Anyhow - you solved my current issue!
Back when Tinderbox started, this wasn’t an issue. For those using a lot of code, I think $IDString is the way to go. Any code that needs a singe or list of $Name or $Path should accept $ID or best of all $IDString.
The other side of this is that $Name or $Path are much more approachable for those taking their first steps with action code —e.g. for an OnAdd or Rule.
HTH 
You might wait a long time. If we need a fix, I think the preferable fix might be to disallow characters “/” and “;” in note names.
But most people won’t encounter this, because most Tinderbox users don’t need so much automation, and because virgules and semicolons are uncommon in note titles.
The overriding goal is to make things as simple as they can be, but not simpler. Second, to make most things easy, and the rest possible.
Let me take another go at my last: $IDString is the informal ‘fix’ for the path issue described.
$IDString is a hash of $ID. $ID is a 10 digit number and in some poser users of action code were getting the odd case where $ID was being used as a number. Being a string $IDString closes that loophole.
$Name instead of $Path. Using just the note title ($Name)name is a convenient way avoid having to remember/write the whole path ($Path). This is easiest for beginners. If a title is not unique, the whole $Path must be used.
$IDString or $ID instead of $Path. Sometimes two notes in the same container have the same $Name so $ID is the only way to tell them apart. Or, titles in the path may contain slashes or parentheses. In all these cases using an ID-based attribute resolves any ambiguity.
You can mix modes according to your skill level and needs.
As well as using the above references, variables holding such reference values can be used as well as designators.
TL;D: For simple tests it is easier to use $Name as this can be read from the screen. For more complex and persistent code, $IDString is a better choice.
Thanks for all the explanations - I’m fine with $IDString - it solves all my issues. In a more general view - allowing the user to enter characters like “/” or “;” in the $Name of a note and getting a $Path attribute that is not able to deal with those characters is just a bug. A very common thing for a complex package like TBX. IMHO good software is characterized by its robustness and fault tolerance, meaning it can handle unexpected situations and errors gracefully, ensuring reliable and consistent performance even in challenging conditions. TBX for me is a great tool and with your help I found my way around the problem. So I’m fine with what I got.
But I can not agree on an argument like $Path is better for “for those taking their first steps with action code”. Without some coding experience it is close to impossible to identify this problem with $Path. So an experience programmer may switch between $Path, $ID or $IDstring - for a newbie $Path is something they should avoid - they will not be able to find the problem if they use the wrong characters. So $Path could end in a very frustrating experience.
Sorry for the long reply - I don’t think this is of interest for many users of TBX. TBX offers so many alternative ways to solve a problem and that’s also characterising great software.
OK, but action code has always worked this way and the ‘fix’ to the issue has always been to use instead $ID—and more recently $IDString (the latter for reasons already explained. A more permanent fix would, I suspect, require major re-engineering of parts of the app. Anyone feeling strongly that this still needs fixing should email support making their case because as users here, we can’t fix things inside the app.
Happily, there is a simple workaround (above). I’m not saying it’s ideal, but it does resolve the issue and is usable now.
My current view on ways to refer to notes:
The big advantage of $IDString, in my view, is that it’s compact and easy to type: “tbx:Bkjtk9” vs. 1687083325. But, as @mwra points out, it also avoids being misinterpreted as a number.
@webline: I’ve had to wrestle with this problem considerably in my projects, mostly due to custom imports from an external system that result in notes being assigned names that include virgules (a.k.a., slashes) and semicolons. The Toolbox that I offered in a prior posting provides one solution to this problem. (See the “(Other Functions)” and “Safe Paths:” stamps in the Toolbox.)
I also agree that the most practical way to deal with the semantic confusion for common (ASCII) character usage is to utilize IDs ($ID or $IDString) as the way to reference notes unambiguously.
Yup, I’ve resorted to $ID and $IDString. Not, this also has the added value benefit of creating cross-referencing indexes in reports.