Tinderbox Forum

Some questions regarding Prototypes and Adornment OnAdds

Morning everyone,

I’m working on an exploratory qualitative data analysis system that works as follows:

  1. I go through a note and zip link anything of interest.
  2. I take the notes that were created through zip linking and I drag them to adornments named after emergent codes, depending on the code I think they belong to.
  3. The adornments add prototypes to the notes according the code assigned that give them metadata I can use in agents later.

I have several questions regarding this process:

  • Is a quickstamp of $OnAdd = $Prototype = “Name of Prototype” a recommendable method to assign prototypes in this use case?
  • What piece of code will remove a prototype $OnAdd? (This is in a use case where I’ve wrongly coded something.)
  • Is there a way to drag a note to an adornment, have that adornment not only assign a prototype but move it somewhere else in the map or document?

Here’s a brief video of this in action:


I think you mean a quickstamp of code:

$Prototype = "Name of Prototype;"

This sets the $Prototype valueof the quickstamped, i.e. selected, note(s). If you wanted to quickstamp notes so that their children set a prototype, then the code is:

 $OnAdd = '$Prototype = "Name of Prototype";' 

Note the outer single quoted as the code we want set already uses double-quotes.

Sorry, to me this parses ambiguously. Are you talking about an $OnAdd that sets a $Prototype value or a $Prototype =value set via an OnAdd action?Forgive the seeming pedantry here, but the two are different contexts (indeed, see the previous section of my post).

Again it depends on what you mean by move. An adornment’s OnAdd can set a $Prototype value and set its $Container to move it elsewhere in the document but I suspect you mean something looser like “not on this adornment or any other”. I don’t believe this eventuality is coded for.

You could try to test that the note is not ‘inside’, i.e. on top of, an adornment. But, even if you can detect this, there is no command I’m aware of that says “put me elsewhere on the map but not on an adornment”. That said, I suspect there is an an unsurfaced assumption in terms of what ‘elsewhere’ on the map might be intuited to mean.

I don’t think I’m missing any built-in processes so this feels like a feature request (albeit with clarification of the presumed result).

Does that help? I may have misunderstood.



in $OnAdd

This will null the setting for $Prototype then set it again.

Just in case KA’s are messed up somewhere along the way this $OnAdd might be useful too:


Hi Mark and Paul, thank you for your replies.

I’m a bit lost in them, so I’ll explain what I’ve learned and also where I still have questions.

This the following screenshot documents a setting that does what I want, which is to assign a prototype when I put a note in an adornment. And to reassign it if I put a note in a different adornment. (I will want to do other things in the future, but for this level of experimentation, this suffices.)

I have also figured out how to move the “processed” note elsewhere in the map:

$Prototype="Code: Growth";$Xpos=50;

Or in a “Done” container:

$Prototype="Code: Growth"; $Container="/Done";

I’m still not clear on how I’d put OnAdd (or otherwise) code on an adornment to mimic the action of clicking “none” in the Prototype handle, as seen here:

Screen Shot 2020-06-07 at 2.03.46 PM

To reset any attribute, set it to [nothing}, e.g.:


This will reset the afected note(s) $Prototype to the default (which in this case is an empty string).

1 Like

That’s it! Thank you.

1 Like

That’s why I suggested the code I did:


which means “Clear all prototype assignments. Then assign “my prototype” to the notes in this container or on this adornment”. Same logic as mentioned above

1 Like

Ahh, I think I get it now. I don’t have a default or inherited prototype, notes are just prototype-less in this experiment, but as evolve the idea, doing so may well come in handy.

Also, I see how you have the Prototype=; in there, was getting distracted by the second part.

I’d re-up on @PaulWalters advice to re-set Key Attributes (or bear that option in mind.

Action code also has a useful code to help in this context. You’ve several hundred notes all using the same prototype but some appear to not show the right Key Attributes (because you accidentally altered them locally and not in the prototype). hasLocalValue() to the rescue. It lets you track down notes with a locally set value for a given attribute. Used in a query first scoped, for instance, to a particular prototype use then you can find the ‘bad’ notes and correct them.

You might do something like this in an agent, to find notes using prototype “Code: Growth” and with ‘bad’ Key Attributes. First the query:

$Prototype=="Code: Growth" & hasLocalValue("KeyAttributes")

Note the latter uses the attribute’s names as a literal string, not as a $-prefix value reference. Now an action to fix the Key Attributes:


By resetting the attribute value it now re-inherits the prototype’s Key Attributes again.

1 Like

:ok_hand: My understanding is growing little by little. Thank you both.

If you have success with this method of moving notes around during qualitative data analysis, I’d certainly be interested to read about it here. I have experimented with “Smart Adornments” for something like this and it works ok. In your case, your adornment that sets a prototype could also set an attribute that satisfies a different adornment’s query, thereby whisking that note away to the second adornment.

However, your method of setting the x/y position is also very flexible. My main concern here is that if an adornment sets this for a number of notes, they would be stacked on top of one another and hidden. I suppose there could be some additional logic added here somehow that would leave one axis the same and increment the other axis by some small number, thereby spreading the notes out a bit. Something to chew on …

At any rate, curious to hear how it goes if you don’t mind sharing.

Thank you for this pointer!

Love this idea.


Thanks @derekvan!

A thought. If programmatically moving notes around, I would set the map\s contents to $NeverComposite=true; and also set that in the parent map container’s $OnAdd, ensuring all new notes on the map don’t accidentally form composites. If you want to use composites, be aware of the possibility of your automatic moving of notes potentially making unexpected composites.

1 Like

Great idea.

1 Like

$Ypos doesn’t matter?

I assume you are in essence sliding the note along the x-axis, so maybe my concern is nil. Just wondering though.

In this particular experiment, I just wanted to see if I could get it off the adornment.