Tinderbox Forum

Creating an agent for overdue tasks

Hi! I’ve been working on a new Tinderbox file for several weeks now.

I called it “Carnet de projets” (projects notebook) and it works perfectly. I am looking for some piece of code which would work for coloring all my overdue tasks, but, whatever I do, I can’t find the good one. I created the following agent to identify quickly my urgent tasks:


But, what about overdue tasks ?
Thanks for your answers.

For agent queries, don’t forget to use ‘==’, so your urgent agent’s query is better written as $Urgent==true.

Colouring overdue tasks, I’m going to assume:

  • Your events use prototype “Event”.
  • Your events have a due date set (in $DueDate)
  • Completed events are marked using $Checked, i.e. ticked on-screen (so $Checked==true).
  • We will set $Color to ‘red’ for overdue items.

Of course if you use a different date attribute for due date, or mark item complete a different want or want to mark overdue items with a badge/different colour/etc. you can just change the relevant code. If you don’t use a prototype, just ignore the first part of the query - the aim is to avoid not testing more notes than we need to, as a matter of efficiency.

The agent query needs to find all Events, which are not complete and where $DueDate is before the current day. As a start we could try:

$Prototype=="Event" & $Checked==false & ($DueDate < date("today"))

But Date attributes are date/times and at midday we probably don’t want items due today and with a before-12:00 time to make as overdue. Working on a day granularity seems better, so:

$Prototype=="Event" & $Checked==false & days(date("today"),$DueDate ) < 0

This new agent will not match an item that is due at any time today, the comparison uses the days(date1,date2) operator. So, that is the agent’s query.

For the action, just set the desired attribute(s):


Note in the action we use one ‘=’ to set an [attribute] equals [value], but in the query we use two ‘==’ to test [attribute’s current value] is exactly equal to [value]

Things to consider. The code above answers the question in simple terms. But consider things like overdue items that get a new (future) due date, i.e. get a new deadline. You could reset the $Color manually when changing the due date, to you could write more code to handle that task. My advice is to not do the latter until you find you really need to. that avoids adding yet more code you may not really need.


I am planning to make this exact kind of procedure part of my next video tutorial. It helps to see your reply to confirm my procedure.

1 Like

@mwra Thank you Mark for your answer. It works very well. @StephenZ Great!

Thanks for posting this! Yes, I realize it’s been here for a long time.
I’ve been trying to incorporate Tinderbox into my workflow for a long while now and this is something basic that I’ve wanted to accomplish.

The example uses $Prototype==“Event” but, that doesn’t work for me for some reason.

My setup
A prototype “Task”
–> attributes: $DueDate; $StartDate; $Checked; $Category, and $Finished - added later to replace $Checked, but I haven’t gotten that to work.

Notes which uses prototype Task (I think I’ve set that up correctly) for each todo item

Agent Querries:
Todo: inside(/Notes) & $Checked=“false”
Completed: $Checked=true
OverdueTasks: inside(/Notes) & $Checked==false & ($DueDate <date(“today”))
UpcomingTasks: inside(/Notes) & $Checked==false & ($DueDate >date(“today+7days”))

So my questions are:

  1. Why isn’t $Prototype==“Event” working

  2. Why does this work: inside(/Notes)

  3. I added $Color=“red” to the action of OverdueTasks but nothing happened. What should I expect to happed?

Thanks to anyone for help or suggestions!


Why not upload a copy of your framework; that would make it easier to understand just what the mistake might be. Some likely culprits:

  • Remember to use straight quotes, not curly quotes, in expressions: $Prototype==“Event”
  • If a task has the prototype “Event”, it should inherit the badge and color of the prototype. Does it?

If I knew exactly what you’re suggesting I would. What exactly do you mean by “framework” ? Also, how do I double check to make sure I am not using curly quotes?


“Framework”: I mean your Tinderbox file, perhaps having deleted any tasks that are confidential. Or delete all the tasks and add some invented tasks.

“Curly quotes”: Most fonts make this pretty clear. “” as opposed to “”.

Another common pitfall: comparison in Tinderbox is case-sensitive, so “Events” and “events” are not equal to each other.

OK, here is the file.NotesAndDailyList.tbx (453.2 KB)

Is this what you were wanting?


Looking at your TBX, the quote symbols are fine, most likely the forum software is auto-correcting code assuming it’s prose. Put a back-tick symbol before after any part of the post you want rendered verbatim. If unsure about back-ticks use the </> formatting button at the top of the box for writing posts here.

I notice your queries and actions are using code styles deprecated since 2009 or even earlier. IOW, just don’t use it there’s no need to use out of date code as it makes your code harder to read and more open to misinterpretation. Help, the tutorial PDFs and aTbRef have all been updated to use current syntax. some older resources, e.g. people’s blogs may possible still use out of date code.

  • Action Prototype|="Task"; should be $Prototype|="Task";. the ‘$’ ensures Tinderbox doesn’t have to guess that you’re trying to set the value of attribute called “Prototype” and not do something else’.

  • = vs. ==. In a query, to test the value of A is equal to the value use == (i.e. two equals characters) or != for not equal to. A single = is used in action code to apply B’s value to A (A=B). Until 2009, a single = was used in queries. It still works to assist those who never revisit/update their old files, but is still now deprecated usage. But, today, always use == in queries, i.e. in

    • agent (and smart adornment) queries
    • find(query) expressions
    • if(query){} conditional expressions

#1. You only have one prototype, called Task. To use a prototype you must first create a prototype of that name. As it is, none of the agents in your test file appears to query for a prototype called agent. In your Task prototype you have the action

#2. This matches every note, or alias of a note, that is a direct child of the root-level container ‘Notes’ (i.e. at path /Notes). inside() only checks immediate children and not grandchildren and other descendants of the stated container. Use descendedFrom() to interrogate all descendants.

#3. It is working! The two notes inside agent ‘OverdueTasks’ have the colour red (i.e. $Color has the value red. The confusion likely arises from a default document setting aimed to assist map use where bright colours are a bit eye searing. Open your TBX’s Document Settings (Cmd+8) and choose the Outlines tab and un-tick the ‘darker colors’ box. You should find colours in your outline look less muddy.

Hi Mark,

As always, thanks for the help, Tinderbox support is great.
I think I’ve followed your response and possibly made the suggested changes - I’m still not sure I understood them all or got them all implemented. But, I now have a couple of other questions. I’ve uploaded the new version.

Goals (for now)

  1. have the title of the “Task” agent = blue - I tried changing the color but it kept changing back.
  2. Have the titles of all other agents = blue
  3. Have all new notes colored:
    1. no due date = blue
    2. due date greater than 1 week = dark green
    3. due date 7-3 days away = light/bright green
    4. due date 1-2 days away = orange
    5. due date today or past due = red
  4. I don’t understand why the “Unchecked - agent” is colored white

At this point, answers to these questions would be a really good beginning for me.


NotesAndDailyList.tbx (462.5 KB)

#1. You don’t have an agent named ‘Task’. The OnAdd for the prototype ‘Task’ includes the expression $Color="blue". This will set a note to the colour ‘blue’ when the attribute is first set but doesn’t stop other agents then setting a different colour. So, your intent here is not clear.

FWIW, if you want tasks to all be blue by default. Set the $Color of ‘Task’ to ‘blue’ and notes set to use the prototype will be blue unless either a) they had a non-default $Color value set before applying the prototype or b) some other effect such as an agent subsequently changes their colour.

The main problem is your ‘Unchecked’ agent, where you’ve failed to consider that by default the query $Checked=="false" so it is matched everything in the document that is unchecked including all your root level notes.

Try something like inside(/Notes) & $Checked=="false", which likely seems closer to your intent.

Also, the same agent has this agent

{$Color="red";} else

In this you are testing the $AgentPriority of the notes being matched. Notes don’t use an agent priority but do inherit the attribute, and its default value of ‘1’. Thus all notes found by the agent are red and for reasons explained notes that aren’t really intended are also set to red.

At this point, I suggest you fix the ‘Unchecked’ agent, delete all the other agent and rest the colours of the root level notes and fix the ‘Task’ prototype. Then start adding back the other agents until it breaks again, then upload.

At present you’ve too many cross-cutting error to make it worthwhile trying to address # in a meaningful manner.

#4. For some reason you’ve set the default colour of $Color to built-in colour ‘7’ rather than the normal default. Only the user can make this change so I guess it’s a by product of some earlier experiment. The learning point here is “don’t build on sand”. Thus:

  • Make a test file, then work on a copy so that when it doesn’t work out you can throw away the file and start over with a new copy. Adding error over error gives you too many symptoms to diagnose at once (as true for the expert user as the starter).
  • Don’t test too many new ideas at once.
  • With agents, test they match only the correct items before trying at add agent actions. IME, this is a big time saver, even if it means delayed gratification.
  • Add test data so you check both the expected and unexpected result - otherwise the latter can obscure an action code error until much later in the process.
1 Like