Coding a system level default edict and rule for a tinderbox document. What attribute option do I use to write action code in a stamp?


I am trying to code a low level, default action code that every note’s edict and rule would default to. IOW as a sytem/edict and system/rule action code. I know I can manually set it as the default here:


My question is, what attribute/option do I use to do this programmatically for a stamp?

Thanks in advance

If you want it to run on every note (I’ll explain below why actually you probably don’t), you would simply set the Document default for $Rule or $Edict via the Document Inspector’s system tab:

Select the desired system attribute and paste your code into the box labelled Default.

BUT, that sets actions on every part of the document including things like the prototypes and hints folders (you may not be using them yet but likely will do as the document grows). I think that by ‘every’ you mean every note that is user-generated content, i.e. stuff you wrote/pasted in a note. Without knowing your proposed code it’s hard to tell the scope.

To set a default rule/edict for your content notes, I’d make a prototype and set the prototype’s $Rule and $Edict (to your planned code) and the prototype’s $OnAdd to set this prototype as the $Prototype. The latter means that all new child notes inherit the parent’s prototype. Now make a new root level container, that will hold all you content notes. Set the container to use the new prototype and now all notes you add under the container will use the default rule and edict without messing up back-of-house root level containers like ‘Hints’.

In the little demo I’ve made note how I’ve added a second prototype ‘pProject’ that has the main ‘pDefaults’ as its prototype. In the ‘Projects’ container, I’ve edited the inherited $OnAdd and it now sets all its descendants to use prototype ‘pProject’. I’ve also locally set the containers colour, so that whilst the container still uses pDefaults it no longer inherits $Color. I’ve used badges and colours to show the divergence of only some attribute as rules are hard to see. Here is what it looks like:


  • Observe how the project themed notes use a red colour but still use the same badge, as the latter is inherited from prototype pDefaults via the notes’ use of prototype pProject
  • I’ve not actually set any $Rule value - you can add your own in the doc I’ll post below.

Here is the document: defaults-sketch1.tbx (182.5 KB). It’s just to show concepts and not intended as a keep-and-complete template. IOW, experiment with the doc but steal the good/useful bits and use them in building your own new TBX.

†. A problem with this sort of planning is—for the newer user—you can’t predict issues of scale. for a 50–100 note TBX no bother. For 100s or 1,000s of notes, I’d be careful in my use of rules for other than very trivial code (i.e. setting colour vs running a long complex set of tasks. I know @TomD isn’t a novice but i think the point is worth making for other readers here who may be less used to large Tinderbox projects.

1 Like

Good points Mark. You are correct, I did intend the user generated notes and my logic did not think about Hints and System “back of the house notes as well” . I have been using the UserPrototype / $OnAdd method you describe for some time. I was exploring other ways of achieving the same. Thinking this through with the help of you and the forum saved me some time.

I think the other lesson here for someone new to tinderbox is to use the forum as I did. Be clear about what you want to accomplish and “ask if it is possible”… In my case, I was curious if this task could be accomplished programmatically via a stamp. What I learned was, it was the wrong question, there was a gap in my logic which I did not consider. The point, this is how we learn. The problem you are asking has probably been asked before or there may be a better question.

Thanks Mark

1 Like

No, not a bad question! It helpfully surfaces some initial false steps otherwise easily and innocently taken.

Thanks for your kind feedback. I accord with your suggestion of asking in the forum. The question might be known to others but is new for the asker. If a ‘known’ issue there are also likely references (old forum threads, demo, aTbRef page) we can offer to help the questioner.

The question unasked is the one never answered. That said, sometimes, just the act of actually writing/framing the question—i.e. articulating it outside one’s mind’s eye—prompts the answer. I’ve certainly experienced that a few times.

1 Like