Applying this stamp:
$Name(children).each(n) {
$Link_url(child[n]) =
$Link_url(child[n]) +
"&search=" +
urlEncode($DisplayName(child[n]))
}
Some children updated, some aren’t.
From reference:
$MyNumber = count(collect(children,$Name).unique);
Trying to debug why it’s not applying to all children. Using this as stamp on a container doesn’t seem to do anything at all.
Also, tried:
$MyNumber = count(list(4+2,9+6));
Nothing.
Maybe TB’s gone AWOL? Tried restart and apparently beach ball of doom’s still a thing 
I’m having to force quit a lot, either my script’s doing something wrong—quite probable because I’ve not written Action Code before—or there’s a bug.
A log and/or debugger would come in handy, if there is one?
Works as a stamp for me:
$MyNumber is 3 as child ‘bee’ occurs twice.
count() and .count do the same so his works equally well:
$MyNumber = collect(children,$Name).unique.count;
In either case, is you omit the .unique then $MyNumber is the count of all child notes, i.e. 4.
Could you post a small document showing the error you are describing. As the code sample works, there must be some other facor at work that’s not (yet) described.
HTH 
Thanks so much, got this working as expected after the restart.
But, I still can’t get the first stamp I posted to work.
See list() which states:
This function returns the evaluated format of each of its comma-delimited argument list of expressions.
So:
$MyList = list(4+2,9+6); // gives "6;15"
$MyNumber = $MyList.count; // gives '2'
Which suggests we need to give Tinderbox a hint we want to count the evaluated output of list(). Extra parentheses work:
$MyNumber = (list(4+2,9+6)).count;
… which sets $MyNumber to the count, i.e. size of the list, of 2, which is correct.
I meant this stamp:
Essentially, when I select multiple containers, I want to loop through their children, and update their $Link_url attributes.
Well the the code isn’t valid action code. First you need to end the individual expressions with a semi-colon. A line break _is not an expression delimiter. Unspoloing the code there is one line, so it’s not that
$Name(children).each(n) {
$Link_url(child[n]) = $Link_url(child[n]) + "&search=" + urlEncode($DisplayName(child[n]));
}
child[n] makes no sense. n is the each() loop variable, which is in turn the $Name of eqch child of the current note.
Withuot a clear description of what you are trying to do, my guess is you are trying to do this:
$Name(children).each(n) {
$Link_url(n) = $Link_url(n) + "&search=" + urlEncode($DisplayName(n));
};
Stamped on to the container, the $Link_url of chach child is set to the existing $Link_url concatenated with the literal string “&search=” and the urlencoded $DisplayName of the note.
If you are trying to do something different, could you please explain a bit more?
You might also want to revisit notes on list.each().
1 Like
Great, that worked. Thank you so much, think I must’ve tried almost every permutation except that 
How come the reference is $Name, should name be unique? Id started playing around with $ID`.
Yes, absolutely! In the worsts case two sam-named notes can exist in the same container because they have a unique ID ($ID) to tell them apart. But, in most cases text titles ($Name or $Path) are easier for the ordinary person. $ID is a 10 digit number, most of use aren’t so got at holding a handful of those in our (human) working memory.
Non-unique titles ($Name) tend to be more problematic is areas like processes analysis/documentation as the same title string is legitimately a non-unique $Name within the doc, needing to appear in a number of places.
If you have non-unique child $Name then $ID might help:
$ID(children).each(n) {
$Link_url(n) = $Link_url(n) + "&search=" + urlEncode($DisplayName(n));
};
Does the same as above. I think my pragmatic take-away is, use $Name or $Path until it’s too hard. why? If you need to debug, and do some logging of IDs, how easy is it to tell 9966999333 from 9966999933 when busy and trying to scan-read a log. Enlightened self-interest means that $Name or $Path are best in most but not all contexts.
1 Like
Good! I’m not sure if you experience/background includes coding or not. Tinderbox is a thought and noting tool that’s grown since 200 which is a long time in software years. At the same time the Web—and Web tech—and the OS have grown (OS9, OS X, macOS, …).
Whether a technologist or a humanist long-term incremental growth leaves some corners in terms of features and OS/web techniques. For instance, Unicode support in 2002 is a long way from 2000, as is HTML. Tinderbox works today but importantly, but unlike a tool written only for today it acknowledges what goes before.Documenting that is confusing as it is hard to tell the speed at which a feature slides to obscurity if not outright deprecation.
So, if confused, a good place is just to state what one is trying to do, avoiding the lazy trap os “like [some app]” as that assumes fellow users have/like/want/can afford [some app]. Plus [some app ] is all too often a shallow recreation of hypertext, which predates the Web.
HTH
I’m probably coming in late, and I’m not totally confident I understand, but…
- $Name(children) returns a list of names: “Jon”;“Jennifer”;“Josh”
.each(n){....}binds each name in turn to n.child[n]normally anticipates thatnis a number, and designates the nth child of the container. But in your case, I don’t thinknis a number.
At this point, we’re well off the rails. Now, I may misunderstand completely! But I thought I’d mention my interpretation to see if that might help.
Suggestion: Consider iterating through $Path(children), which provides the full path to each child note. You can use that path as a designator, avoiding the need to index the children and also avoiding ambiguity if there’s another Jennifer in some other castle container.
Suggestion: When a complicated action misbehaves, it often helps to break it down into smaller steps, saving intermediate results in spare attributes. That makes it easier to see discrepancies.
2 Likes
Thanks, this all makes sense now.
The sporadic behaviour was because child[n] is indeed meant to take integer based keys, ie, an array, not a dictionary or hash or whatever; but, you can pass it strings, without error, which somehow have some equivalence.
Not an array, that is not what the [ implies even if so used in other scripting/code systems. The child designator (see here), used with no qualifier, represents the oldest child (note) of the note currently in focus.
Optionally, the user may supply a single unquoted integer (i.e. not an array) within square brackets. This integer is a zero-based count of the children in $SiblingOrder, where 0 is sibling order 1. Thus child[0] is redundant usage as it refers to the same as child[0]. The apparent duplication is because the integer based usage didn’t arrive until v6 in c.2015, whereas child has been around since at least v2.3.4 in 2004.
If passed an expected input Tinderbox will do its best to figure out your intent and corrects your error on the fly. So, if you put code child["2"] it will evaluate it as if it were child[2].
Action code is macro system that has grown according to need rather than a language planned from the outset. Thus assumptions based on use of some other language are often misleading. I note that note as critque but observation of similar mispresumptions observed in the past.
HTH
Thanks for adding some details.
Personally, I understand this to be array-like behaviour, concepts and behaviours vary. Action Code’s one reminds me of JavaScript:
test = [1, 2, 3]
(3) [1, 2, 3]0: 11: 22: 3length: 3[[Prototype]]: Array(0)
test[0]
1
test["0"]
1
typeof test
'object'
Array.isArray(test)
true
test returns the entire object…or array or whatever…but it could return whatever the implementors decided to return.
I didn’t explain very well before. My point was that I understand now that when child[n] receives a string, it doesn’t treat that string as a note name that refers to the intended note; but instead it, assumedly, coerces the string and points to…who knows.
Could figure it out, but can’t think of any pertinent use cases. Maybe to mess with people’s minds or, possibly, job security: still one of my favourite tech talks
My earlier comment about not trying to think of action code as like [insert language]. Those who seem to get most confused are those want action code to behave in a way it doesn’t but which to the them seems familiar—which I get. But, best is to use the available docs and use the examples given and not parse the examples into whatever you’re more used to. Action code is what it is and is and bar some scars of longevity (and need for legacy support) it is pretty consistent. But it borrows metaphors from several different places which is why trying to understand it in terms of, for example JavaScript, will likely only make things more difficult.
Writing open ended tests, such as you might in a programming language, don’t help much. The best way to pick up action code, both from personal experience and watch/assisting others, is to give yourself a project in Tinderbox—and something you know to be achievable in the app. That way you should be able to get it to work and others here can help ±hopefully—to explain initial complications.
Though Tinderbox data has a notion of data types, Tinderbox will coerce where necessary. IIRC, it was originally with the same sort of hope as AppleScript, that the user would just write what they wanted to do in plain language and he app would figure it out. That proved more problematic as action code’s feature set grew, so more formal behaviours, e.g. explicitly quoting input characters (that you know or intend to be) strings. But, for legacy support, Tinderbox will still likely cope.Thus today, to set a note’s map icon/outline title to blue, now we’d use:
$Color = "blue";
but, if not confused by other code, this older form might still work:
Color = blue
Tinderbox will find an attribute Color and a named colour blue and figure it out. Note in the latter, the lack of a ‘$’-prefix for an attribute reference, an unquoted string literal and no expression terminator. I mention this as it might help explain why the various documentation, examples online, etc, may have some ambiguity.
For my own part, in the notes I’ve written in aTbRef, I’ve erred on the side of express/verbose code form as many users here have not background in, or interest in, programming. Thus ‘rules’, even if flexible in truth, help those for whom nothing is obvious (compared to those with coding experience). Also my notes are the result of black-box testing (I’m just another user and can’t see under the hood of the app), so the how/why some things remain a mystery.
Tinderbox is a large and long lived Toolbox that has always only lived on the Mac and has taken advantage of OS features which themselves have changed. The app came out in System 9 days and has moved via OS X to current macOS, including a complete codebase re-write to move onto Xcode c.2015. There have been a lot of releases over the app’s life, so there will be the odd obscure feature. But, if we don’t personally need it, we don’t have to use it.
If you’re trying to get a feel for the evolution of the app’s coding mechanisms, I keep 7 previous baselines of aTbRef (see list here) for just that sort of exploration.
HTH
1 Like