I added two additional displayed attributes to an existing prototype for my notes on the assumption that OnAdd Action in an existing container where earlier notes were housed using the previous version of the prototype would pick up the changes. No dice. What is the likely problem?
If you update the Displayed Attributes for a prototype, it has nothing to do with $OnAdd.
Meanwhile, all notes using the prototype will inherit the new Displayed Attributes ($DisplayedAttributes) except if they have different $DisplayedAttributes set at note (local) level. It has no effect on $OnAdd.
Please forgive me for being thick on this subject. Here is the case:
- I have an existing prototype with 5 displayed attributes, two of which are user defined.
- I have a container with an OnAdd action that assigns that prototype to any new note created in the container (or otherwise added to it)
- There are about 250 notes in that container using the original prototype.
- On the principle of TBX flexibility, in the process of curation, I decided to add two additional system attributes to my displayed attributes in the original prototype.
- I now find to my dismay that the old notes are unchanged (that is, they still show the original 5 displayed attributes). Morever, any new notes placed in the container still display the original 5.
- In short, no change of any kind proceeds from the modification of the prototype.
Does your OnAdd action set $Prototype, or does it set $DisplayedAttributes? If these notes had their own values of $DisplayedAttributes, that would override the inherited value.
But all is not lost! If this is the case, the action
$DisplayedAttributes=;
removes the value that was assigned and restores the inherited value. You could do this with a stamp or an agent. Or, you could use Quickstamp.
My OnAdd action sets $Prototype. Does that affect the remedy?
Can you share the file here? Or send it to tinderbox@eastgate.com? It shouldn’t be hard to see what’s going on.
Or, try the solution I mentioned above on one of the notes; that should resolve it.
Thank you Mark. I shall try the experiment on a note.
A solution:
- Created a duplicate file for experiment.
- Created a new Notes prototype. It contained the original five displayed attributes plus the two newly assigned.
- Created a stamp to assign the new prototype.
- Tested on a single note.
- Selected all the target notes and applied the stamp.
Result: All target notes now reflected the displayed attribute package of the new prototype and retained values assigned to the original five attributes.
It seems to me that you’re experiencing the by-product of inheritance, as noted by @mwra above.
A note will inherit changes from its prototype; however, if you’ve locally changed your note in any way, e.g. the $DisplayedAttributes, the inheritance chain stops as Tinderbox does not want to overwrite any of the local changes you’ve made on that note.
You can easily tell Tinderbox to go back to inheriting the $DisplayedAttribute list from the prototype. NOTE: This happens to me all the time, as I’m constantly curating and making meaning out of my notes (you’ve not done anything wrong; in fact, you’re doing it right).
Here are the two easiest ways you can go about reestablishing inheritance to the $DisplayedAttributes list:
- Hit the Rest Button
Open the $Displayed Attributes dialog box and hit the reset button.
This work great for one note, but is a pain if you want to do this for many notes at a time.
- Create a stand and apply the rest via a stamp
Create a stamp with the following:
$DisplayedAttributes=;
Select all the notes you want to update and then apply the Stamp. This will reestablish inheritance to the prototype and reset the $DisplayedAttributes for all selected notes.
Please let me know if this helps.
1 Like
Also there is a more general article on inheritance in this Clarify doc, and in this section of aTbRef.
As well as resetting Displayed Attributes (as illustrated in the post above) you can search for items with a local value set for an attribute via hasLocalValue().
1 Like
Thanks to Michael and Mark A for help and suggestions.
Unfortunately the $DisplayedAttributes=; reset via a stamp does not work with this file. This must be owing to some error in my set up. No worries, as I can make the changes in this file via a new prototype applied with a stamp.
I must say, however, that this experience has made me a little skeptical about curation flexibility via prototype development (addition of new displayed attributes). I do not look forward with confidence to my next round of file design. It might be useful to have a short lesson focused directly (and narrowly) on this specific case.
I’m sure there’s some detail that’s getting in the way. If you could share a version of the document, I’m sure we could quickly solve it.
@wajakob If you can’t share your file, let’s hop on a zoom call. Message me, I’ll send you a zoom link, and we can straighten it out, I’m sure.
Mark B. How do I send a file directly to you?
Problem solved! Error in my setup. Thanks to Michael Becker!
You bet. Actually, this is a great teaching moment.
Remember: Tinderbox lets you have notes of the same name, even prototypes. Prototypes can be anywhere in your file. Any file can be a prototype if its $IsPrototype attribute is true.
Turns out that William had two prototypes of the same name, just the one and it so happened the one assigned to his notes, got buried in his site hierarchy. So, when he was updating the secondary prototype his notes where not inheriting the change since they were linked to the first one, which justifiably caused confusion and frustration.
We identified the issue by rt. mouse clicking on the little yellow box to the left of the note name in outline view (see below for example) to see the prototype list and quickly determined that there were two prototypes of the same name. We did a search on his file, found the first prototype, put it back into the top level of his prototype folder (just for convenience not for functionality), and deleted the secondary prototype. Problem solved.
Here is a sample image of the prototype dropdown list:
2 Likes
after the workshop I played with the OnAdd attribute. I added a 2nd attribute “AssignPrototype” to my “pFolder” prototype and wrote into the OnAdd attribute: $Prototype=$AssignPrototype;
But this doesn’t work - no prototype got set to a new note. If I change the action code to $Prototype=“pPerson”; it works fine.
How can I use the value of an attribute in action code?
If my prototype stores a value for an attribute as default and I overwrite the value in the note using this prototype - how can I access both values - the one from the prototype and the one of the note - both using the same attribute name?
Thanks a lot!
It has to be the exact name of your prototype. I suspect your prototype is named “Person” not “pPerson”. Try $Prototype=“Person”;
We will show that next week.
If I pass the name as a string value like in =“name” it is no problem. But if I write the value into an attribute of its own and try to refer to this attribute like in =$theAttributeName I fail.
I see…yes I played around with that before. Passing attributes around like that might work in different contexts, but so far I’ve not be able to get it to work directly like you’re trying. It creates some kind of circular reference. I wanted to have a different attribute as a drop do that I could use to swap the attributes used for a note. I ultimately landed on the idea that I’d just display the prototype attribute and swap prototypes this way.
Another way you might try is to run a collect to get all the names of the prototype and to populate the $AssingPrototypes, e.g. $AssignPrototypes=collect(children,"Prototypes");. You could then have some action that would they for through the steps to assign the prototype name. But again, if you’re just looking for a display attribute to assign the prototype, the most direct approach is to do what I show above.
1 Like