I have a document with many notes, all under a single prototype note. I want to add a tag attributes box to all notes in the documents, all at once. What’s an efficient way to do that?
Many thanks in advance.
I’m not 100% sure as you your meaning but I assume you want to add the built-in $Tags attribute to the Displayed Attributes of all notes using a single prototype? If so…
- Select your prototype note.
- In the text pane, top right, look for a ‘+’ button, to the right of the note’s title text (as illustrated here).
- Click the ‘+’ button, and the Add Displayed Attributes pop-over opens. In the top box, type
Tags(note: no $ prefix) and then click outside the pop-over to close it. - The prototype should now show the Tags attribute as a Displayed Attributes. All notes inheriting from the prototype will show the same Displayed Attributes, unless…
- If a note is not showing (i.e. inheriting) the correct prototype Displayed Attributes, with the affect note selected —not its prototype_ click the ‘+’ for the Add Displayed Attributes pop-over and click the ‘reset’ button, then click outside the the pop-over to close it.
If you need something else, can you please give additional clarifying details?
I also cannot understand Tindebox’s prototype logic within a hierarchical structure.
I have a note P, container, with notes 1, 2, 3 … preexisting. I convert the note P into a prototype with attributes ( Tag, Flags …). In Action, in Prototype Inspector, I include: $ Prototype == “Note P” ;.
It would be expected that the attributes of Note P would be expressed for pre-existing notes 1, 2, 3 …, which are Note P containers.
However, this is not the case because Tinderbox prioritizes not altering pre-existing notes, it seems to me.
In terms of usability, whoever makes a prototype wants its effects to affect all pre-existing notes, unless one of the notes adopts another prototype.
It seems to be a design option where it was preferred that the new prototype does not affect pre-existing simple notes.
I’m new to Tinderbox and the chance of being wrong is very high. I would also like to know how to make a prototype affect pre-existing notes in a hierarchical structure (containers).
There might be a confusion caused by conflating several items.
- Setting an $OnAdd action in a container note that has existing children, does not automatically apply that newly set action to the existing children. “OnAdd” means “when I add a new note to the container”.
- Making the container into a prototype, does not cause any sort of inheritance of that prototype to the children of the container.
- The syntax $Prototype==“Note P” does not assign prototypes to anything. The == operator is for comparison, not for assigning. For assigning, use “=”.
Best practice:
- Create your prototypes in their own root container – most people (and Tinderbox when inserting Built-In Prototypes) use the “Prototypes” container.
- To change the prototype for existing notes in a container, use an agent, or a stamp, or select the notes, control-click the indicator to the left of any of the notes, and pick the new prototype.
- In an $OnAdd action, use $Prototype=“myPrototype” (using your own terms).
I hope this addresses your concerns, as the original situation and question as explained in your post was not 100% clear to me.
2 Likes
don’t give up. It isn’t complex. If you take a look at my notes on Inheritance of attribute values, especially the section on `Attribute value inheritance flows downwards’.
No, that is not true; in fact, prototypes do affect (update) attributes pre-existing notes as the linked articles above should make clear. What program are you using as your frame of reference here? I’m not use to seeing inheritance in the form your describe. sometimes, using on particular app a lot creates false assumptions about how all apps ru—it’s not an issue of right/wrong, sometimes one’s assumptions don’t apply in the context at hand.
As @PaulWalters has explained, you had an unexpected result because you’ve assumed or miss-understood how prototypes work. Tinderbox’s prototype-based inheritance is more powerful than a purely outline-based inheritance, not least because an outline is only one of the ways of viewing your data.
One more starting tip is to use a new document when learning a new feature and which you’ll delete when done; if you need specimen data, put some in a Tinderbox document and work on copies of that file. That way you can experiment without building up cruft. When you understand how a technique, e.g. inheritance works, you can apply the technique correctly without tipping over past failed experiments. This gets around a common starting experience where inheritance seems patchy but is in fact works, it’s just the user has set—when tinkering_ local value in notes
Don’t give up!
What you’re trying to do should be straightforward. But there’s just enough ambiguity in your question that two very experienced Tinderboxers (who were awake earlier than I) weren’t quite sure what you wanted.
One source of possible confusion is that the Tinderbox hierarchy is not involved with inheritance. For example, the note War And Peace can inherit from the prototype Novel and be inside the container named Bookcase In Study.
If you could, perhaps you could step back and tell us a little about your project. What are you trying to do? What sort of notes are you working with?
There must be a simple answer to this, or should be one!
Here’s a bit more detail on what I’m trying to do.
I make a document.
I make a prototype.
I start adding notes, all nested within the prototype note.
Later, I decide I want to add Tags as a displayed attribute, for all notes, existing and new.
In other words, I want to make sure that every note nested inside the prototype, and all new notes added within the prototype, has the Tags attribute displayed – every single note.
Is that possible?
If I can clarify further please let me know.
Thanks very much, R
PS, the way I’ve been dealing with this in other documents is to remove a note from prototype nesting, then add it back. That gives me what I want. But for some documents that’s a long, laborious process.
First: the prototype of a note is not typically an ancestor of the note. For example, “Buy groceries” might use the prototype “Task” and be inside the container “Errands”. So, let’s move your notes outside the prototype for now! (You can move them all inside a common container — that’s often a good idea!)
Now, if all these notes have a common prototype — call it Task – then changing $DisplayedAttributes for the Task will also change it for every note. (Exception: if a note has its own value for $DisplayedAttributes, that overrides inheritance.). So, that would solve your problem.
… a good reason why it is not a good idea to put notes inside a prototype, is that if you ever happen to use that prototype in a different context – assign it to a different note outside of that container – then you’re going to cause that note to inherit copies of all the children of the prototype. Life can get very messy very quickly when that’s the case.
1 Like
Thank you. Maybe best to show exactly what I want to do:
This is the top of the outline in a long document. I recently added the “tags” box to the prototype:
You can see that child notes inherit the Tags box:
But anything nested below that level does not:
I would like to add the Tags box to every note in this voluminous document, as quickly efficiently as possible.
Thanks! R
Taking into account what’s suggested above regarding prototypes.
Let’s say your root container is “My Notes”.
An agent such as this will then do what you want:
You can do the same with a stamp that you apply to all or selected notes.
1 Like
Another ‘fix’, if you really want every note to show tags, you could set the document’s default for $DisplayedAttributes to ‘tags’ using the Document Inspector’s system tab, so it looks like this:
But, as a general approach I’d not recommend it. Here’s an approach that uses Tinderbox aligned with its design intent. Assuming the container created by builtin prototypes doesn’t exist we’ll add one, using File menu → Built-in prototypes → Event:
This is useful as any note added to this container is automatically set as a prototype. Now select ‘Event’, press Return to make a new note and call it ‘pNote’. The title’s prefix is to remind us this is a prototype - you can use a different prefix or none, but it’s a practice many users employ:
You can now delete the ‘Event’ prototype (if not otherwise needed). With ‘pNote’ selected, use the method I described to set $Tags as a Displayed Attribute:
With this result:
With ‘pNote’ selected open the Action Inspector action tab, to set its $OnAdd action. Add the code:
$Prototype = "pNote";
Like so:
The prototype is ready to use. We’ll make a new root level note ‘DATA’ to hold all your notes and we’ll set it it to use the ‘pNote’ prototype. Open the Properties Inspector, Prototype tab, and from the ‘Prototype’ pop-up list, chose ‘pNote’.
Note: in the following images I’ve set pNote’s colour to a non-default colour so it’s easier to see if a note uses the prototype:
Now, with ‘DATA’ selected, press Shift+Return to make a new child note. Name that and with the child selected, repeat the process.
Without any extra effort, note ‘bb’ has the correct Displayed Attributes, and if you alter the Displayed Attributes in pNote’ _all notes using the prototype will update to show the same items.
Now, in your doc, you may have already set $DisplayedAttributes in some notes, so when you try to apply the method above the Displayed Attributes may look wrong. This is because the ‘wrong’ notes have a ‘local’ value for $DisplayedAttributes and local values always trump inherited ones. Fixable easily? Yes, reset the attribute. The easiest way to do this is to make a stamp with the code:
$DisplayedAttributes=;
Use the stamp on the notes with the wrong Displayed Attributes and they will once again inherit as expected—in the Tinderbox sense at least. 
HTH
Those are all excellent suggestions. I tried each and the Stamps method works best for me in my situation. Amazingly I’ve never used Stamps before. Now I know I know what they’re about. Can’t thank you all enough.
Best
R
1 Like
Great, glad you’re moving ahead. Swing by if you get stuck again.
1 Like
Russ, sorry I have missed this colloquy, during other duties. I appreciate your asking questions like this, because it really is through this Socratic method that we all have made our progress with this software. And thanks to the local experts like @PaulWalters and @mwra for sharing their knowledge, which I have drawn on many a time. Plus of course @eastgate
Ah, yes, Stamps: I use these all the time. I’ll spell out my use-case a little more, to give you a further specific example.
In many of my files I have a drop-down menu of stamps i might want to use. You create, edit, or delete these by choosing Stamps/Inspect Stamps from the command bar. For instance in one file I have this:
The stamps listed there are all ones I have created. Archive stamp is when I want to move items to an archive container; Done when an item is finished from the to-do list; Scanned is to signal that I’ve taken a step in processing them; SquareAndRed when I am changing the map appearance of some items I want to highlight in a map; and so on. (TransferToBig is when I am choosing items to transfer to a “Big Projects” file.)
Here’s a sample of how the Inspect Stamps command lets you set up a stamp. This one shows the steps included in the Done stamp:
Translated, this sets the $Done attribute to True, and it records the time when the item was finished. It also sets some other attributes (Next and Waiting) back to their default value, which is False.
How do I use these? One by one on items as I finish them or decide what to do with them. Or if there is a block of them I’m ready to handle all at once, I select that group and then apply the stamp.
Stamps, and the Attribute Browser, are my two Most Valuable Player candidates – for my own personal use of the program.
3 Likes
Jim, thanks so much for taking the time to put this together – especially given all that’s going on in the world right now. Enormously valuable. I can see several ways Stamps will make my life easier.
Thanks to everyone else here too, for the generous spirit that transforms the learning curve for Tinderbox from a big hassle to …well to less of a hassle. 
The program is great, and wouldn’t be near as flexible and adaptable if it were stupid easy to get the hang of.
All Best
R
@hrmhrm, here is one I learned from @TomD the other day. In stamps you can say
If you name your stamps like this “Menu: stamp name” you’ll get a menu in the staps drop down. This is GREAT when you have a lot of stamps.
2 Likes
REviewing the above, I’ve updated and improved my articles on the Stamps menu (the image now shows a grouped sub-menu) and on Stamps (a fuller description of stamp groups).
2 Likes