Tinderbox Forum

Getting the name of grandparents note

How do I get the $Name of the grandparent of only those notes with a specific Prototype?

Example: note B’s subtitle should get the title of chapter x (0).
$Subtitle= (…) ?
image
Hint:
chapter x and chapter y are $Prototype=“chapter”
note A, B, C are $Prototype=“note”

Don’t overlook the grandparent designator. In a rule or edict:

if($Prototype(parent)=="note"){
   $Subtitle=$Name(grandparent);
};

If running the code on an alias, e.g. in an agent action test $Prototype(parent(original)) instead.

Thanks, Mark. But I’m looking for a more general rule: Going up the hierarchy and give me the name of the second note with Prototype=“chapter”

In this case your code would give note C the subtitle of chapter y's name. But I’m looking for chapter x's name.
image

That’s a different question and more open-ended. I don’t think that’s possible until you define your logic more clearly - automation code works better with some clear rules to interpret.

I’m confused by the diagram with the nested prototypes. Unless you’re bequeathing children as part of prototype assignment you don’t want to be nesting prototype, and even then with care.

Why are ‘chapter x’ and ‘chapter y’ separate prototypes? Are there two types of chapters? Is the ‘x’ sort of chapter always at the same outline level? Are the numbers at the end of the chapter title or part of the actual name or added via a display expression (i.e. is what you see as the $Name actually a different $DisplayName, in case that affects your code). At present we’re asking a sort of vague “Show me the piece of paper I was holding yesterday” question whereas we need some logic.

Speaking from experience, trying to automate ad hoc structures is often resolved by formalising the incremental structure. IOW, rather than make odd code to answer loose question, changing the structure/naming/prototyping to a more coherent whole allowing simpler code is a long-term win.

OK, I understand - I probably explained it too confusing.

Let’s try it this way:
Let’s say, I’m writing a book with TBX with notes for chapters and text, where chapters can contain subchapters and notes can contain subnotes.
Now I want to build an agent which collects all text notes. But some notes have the same title (e.g.: Intro, End). To see where this collected notes came from I want to insert their main chapter in the subtitle. So I clearly see: noteA from Chapter 2.
(I assume this is a common task in TBX.)

Sort of - people do use Tinderbox to write or prepare books, but it is not a book-writing app so there in no one right way to do this. IOW, you are looking for a solution not the solution that your comment implies.

I’m real busy for next week and this is a large topic (can others step in?) but a few pointers. You’ve just surfaced an assumption: chapters contain zero or more sub-chapters (are there sub-sub-chapters?) so you should plan for a chapter prototype and a sub-chapter prototype† and keep them in the /Prototypes container with the built-in prototypes‡. Now we can more easily see that a note, even in a sub-chapter will only have one ancestor note with the chapter-type prototype.

† Tip: when naming prototypes, use a prefix or suffix - one you like - such that prototype note $Name is no one you will use elsewhere. For instance ‘pChapter’ is unlikely to get used as a title for some other note.

‡ If you don’t yet have that container, add a built-in prototype from the File menu and Tinderbox will create it (you can always delete the newly added prototype if not wanted).

To set $Subtitle to the name of the ancestor note using a prototype called “pChapter”, try this as an edict (code not tested):

$MyList = find(ancestors);
$MyList.each(aNote){
   if($Prototype=="pChapter"){
      $Subtitle=$Name(aNote);
   }
};

Why an edict not a rule? You only really need to run this once and then occasionally in case the note moves. That is exactly what an edict does. A find() task has to poll the whole document and as it grows, and each note is doing this task you can see it becomes a lot of unnedded constant checking.