OnAdd not working

I am trying to use OnAdd as part of a pRoom prototype so that when a note is added as a child it is given a pToDo prototype and an attribute.

The kitchen note is based on the pRoom prototype which has OnAdd with the value

Each prototype has a symbol associated with it so I can see when it is applied.
when I put a note under kitchen, nothing happens.

I have looked at the tutorial from Michael (which is great) here: https://www.youtube.com/watch?v=6bVFeg_sfN8

For some reason what I am doing is not working. When I add a child note to ‘kitchen’ nothing happens.

does anyone have any idea what I am doing wrong, or is there a way to debug this you might recommend?

thanks, Frederick
todo-test.tbx (84.6 KB)

Uploading your document would help, if possible.

Be sure the quotation marks are straight quotes, not curly quotes; the forum tends to convert them to curly/typographic quotes.

I’m not sure how to upload, didn’t see that option in the interface. I must be missing it.

thanks! I uploaded it. Somehow I didn’t expect upload to with the text editing tools - kept thinking it would be with the link and other icons…

Pretty straight forward. Few issues.

  1. The Kitchen note was not showing the correct (inherited) displayed attributes

To fix this rt. mouse click on the note and click Reset. This resets the $DisplayedAttribtues inheritance to the prototype.

You’ll note that the $OnAdd is emply. It is not inheriting from the prototype.

  1. Fix the $OnAdd inheritance

Rt. mouse click on the $OnAdd and select “Use Inherited Value.”

  1. Curly Quotes
    In the $OnAdd, the first quote was a curly quote; not a straight quote. I added and set the $SmartQuotes to false so that I could edit the $OnAdd action code that I pasted in the text. This tells Tinderbox not to covert quotes to curly quotes. Then I pasted the action code back into the $OnAdd.

Works fine now.
todo-test.tbx (122.3 KB)

Thanks Michael!

So what did I learn here?

  • I need to be careful of smart quotes and turn them off if writing action code
  • I need to be careful when creating a note and later trying to use prototypes and action code - this might require a nudge to update the note to use inheritance, by doing 'Reset" and forcing inheritance (did I get this right, that this was an artifact of the order in which I did things?)


1 Like

A note inherits values from its prototype unless it has a value itself.

Another way of saying this is, “in nearly all respects, a note looks like its prototype unless the note says otherwise.”

So, if the prototype A Room is green, and kitchen inherits from A Room, then kitchen will be green unless kitchen already has a color. If kitchen is red, it doesn’t inherit: it knows it’s red! If you want it to inherit, you can remove whatever color it has: “you’re a room now: act like it and be green!”

1 Like

BTW, for TBX files you can also drag drop onto the forum post’s input box - i.e. where you are writing your note. Same for JPG/PNG screen grabs.

Inheritance in Tinderbox: You might find it useful to read this section of aTbRef: Inheritance of attribute values.

Viewing actions: this isn’t an issue of right/wrong to this, but unless an action is very short (rarely the case) viewing OnAdd or Rule, etc. code as a Displayed Attributes is not always as helpful as imagined. When starting out it is much more helpful to you to view actions (OnAdd, Rule, Edict, etc.) in the Inspector. Then you can leverage the syntax colouring. Also there is no need to worry about auto-substitutions like straight/curly quotes as that only occurs if you type in the $Text of a note. Also note, you can re-size the Inspector, for instance so you can see a line of code without (soft) line wrap.

So from your test file:

We see the red colour, used to denote double-quote enclosed strings, starts at the second double quote in the code. Aha, the first must be the wrong type; we needn’t worry why, and just fix:

Another ‘aha’. We’ve fixed the quotes, but $Room is in black but $Name is in magenta. Why? Because $Room is not recognised as an attribute defined in this TBX. From experience, I know $Room is not a system attribute, but if unsure, checks this listing of system attributes. Sure enough, there is no listing for $Room. Therefore we need to make a user attribute of that type, I’d suggest a string:

Document Inspector: todo-test 2024-02-19 09-52-03

Now our action looks OK:

Tip: an attribute reference, e.g. to ‘Room’, is only coloured if it has a $-prefix and is both spelt correctly and—for non system attributes—defined in the current TBX. So mistyping an attribute’s name would leave the name un-coloured even with a $-prefix. Another good reason to use the Inspector is it will suggest auto-complete for (known) system and user attribute names.

But, let’s do one more tidy to help us learn. The code above shows how the semicolon works in action code—it separates discrete actions, otherwise called expressions. You can add a semi-colon after the last expression. Tinderbox doesn’t demand it but is untroubled by it. Whilst those with coding background that is enough to make sense, for many others this is all a bit like magic. So, I’d suggest that whilst finding your feet, put each expression on it’s own line and add a closing semi-colon. It’s as much for use as it is the app—we’re signalling out intent you ourselves. So:

This also shows why displaying actions in Displayed Attributes doesn’t always have the desired result, as only the first line of code shows up. Now we can add $Room as a Displayed Attributes to pToDo. Re-add the ‘foo’ note to the ‘kitchen’ container and we get:

todo-test.tbx 2024-02-19 10-02-09

You also asked at the last Tinderbox meet-up how to change the badge of a note if it is checked ($Checked and see Checkboxes). We’ll added $Checked as a Displayed Attribute for prototype ‘pToDo’ and give that prototype
the following rule:

You could write this all on one line, and it would work, but laid out like this it makes it easier to check you’ve coded what you meant to, e.g. getting correct pairs of {}, etc.

Now we’ll add a new room container, add a ToDo task to it, and check (tick) it as done:

Another way, in outline view, to use $Checked is to turn on checkboxes (see view menu):

[Note: if doing lots of these actions, consider using an edict rather than a rule. But a rule is good for initial testing of the concept—though note it runs all the time, which perhaps overkill for the task.]

Things we’ve covered:

  • The inheritance chain
  • Use of Displayed Attributes
  • Best place to see/edit action is the Inspector
  • Using action code syntax colouring in the Inspector to find code faults (wrong quote character, undefined user attributes
  • Checkboxes
  • Setting badges based on $Checked

Here is a version of your document with the above changes (I turned visible checkboxes off in the saved document): todo-test-fix.tbx (112.9 KB)


Mark - thank you so much for taking the time to write this, it is fantastic and very clear. Thanks for helping clarify all this.