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:
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:
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)
