This and that designators

I don’t have any specific application for them right now, but I’m not grasping how this and that works. I’ve read both this and that and the help file, but if someone could step me through the following, it’d help in me understanding.

If I have an agent named Foo and some notes named Bar and I want to change the name of the notes to Foo, I was thinking you could just put the following in Foo’s action code and it would do it:

$Name=$Name(that)

However, it doesn’t work. I’m obviously missing something conceptually.

I understand that you can pass the agent’s name in other ways [such as $Name=$Name(agent)], but I want to get to grips with this and that. I can’t think of a similar example for using this, so if someone has a simple scenario that explains the use of this, that’d be great.

Thanks in advance.

I think this and current really derive from conditions that can arise with (more complex) HTML scenarios than with action code per se. In most cases the default locus of an action code is this so doesn’t need to be explicitly stated. In simplest form, these are the same:

$MyString=$Name;
$MyString=$Name(this);
$MyString=$Name();

If the note is called “ABC”, in all three cases $MyString would be set to “ABC”

The referenced article on that states:

For instance, it makes it possible to to use an attribute value from the calling notes within a find() query in an expression. In such contexts, ‘this’ would apply to the note being queried by find() rather than the note calling find().

The point being that within the scope of a query run via find() in a query, the value is this differs from normal. Perhaps we wish to find any “Event”-prototyped note where $MyString equals the $Name for the note running the find, e.g. in a rule, edict or stamp. We might write:

$MyList = find($Prototype="Event" & $MyString==$Name(this));

or as we know from above it is the same as this code

$MyList = find($Prototype="Event" & $MyString==$Name);

But, neither of these queries works as intuited as the second form shows more clearly. Why? Because within the find(), as each note with the “Event” prototype is tested this becomes the note being tested, rather than the note running the find(). To make the query use the $name of the note running the find() we use the that designator.

I’ve just updated my aTbRef note to reflect better the description here, above. @eastgate may correct me, but at present I think find() is the current place where the that designator is needed (at present!)

Many thanks for that. I’ll consider both something more for edge-case use, especially with find(). I had wondered about this – it did seem to be basically implicit and your example has confirmed that.

1 Like

Neither are edge-case, per se, but rather for relevant circumstances. If you don’t need them don’t use them. If you end up doing something that does need them, I’d wager the documentation (or replies to forum Qs) will tip you off a to the need for usage.

As for this it seems it was used more in the early days of Tinderbox and can be useful when trying to tell Tinderbox the context of data is this or current (qv). I suspect that context arises more in formatted export (aka HTML Export) as opposed to in-app action code. Bear in mind action code isn’t a pre-designed coding environment but rather a scripting system that has grown and expanded - mainly in response to user requests) over the 18-odd years [sic] that the app’s been around. Originally, what is now export code was the primary scripting method and queries originally had their own coding method.

I think people with a coding background/expertise tend to trip up on an intuited assumption that action code is a programming language. If you think of it as a macro language that has grow in ad hoc fashion, it helps. IOW, instead of assuming features, you need to go look at the Help/docs, e.g. for action code. That fact doesn’t detract from action code’s capability but does explain why basic programming things like elseif or case statements and such don’t ‘just’ exist in action code.

Good clarification. Thanks.

I have to say (although I’m still very much a novice), for something that has grown ad-hoc it has a pretty remarkable cohesiveness to it. It took a while to sink in, but I can now see why Tb has grown its cult status. The ability to go as simple or as complex as you want with it makes it so adaptable to an individual’s requirements. There are plenty of other purpose-built single-task applications that may look prettier, but not much has the adaptability of Tb.

3 Likes

this refers to this note: the note being examined by an agent, or the note whose rule is being run, or the note being moved into a container or adornment with an onAdd action. this also refers to the note being examined inside a find() , collect(), or **collect_if()**clause or other implicit closure.

But what happens if you have a Rule which uses find()? Inside the find(), this is bound in turn to each note in the document. How can we refer not to that note, but to the note whose rule is being run? We use that to refer to the enclosing this.