Hi, once again I’m coming for help on something that should be simple, but that I’m struggling with.
I would like use either Badge or Progress bar, or anything, to indicate volubly which notes have been recently modified or created. I want them to remain in context (i.e, they’re date events and I want to be able to see them in the Agent container that is collecting and displaying all notes in chronological order.
So far I’ve got $Modified==("yesterday") & $Prototype=="Event";
with an Action of $Badge="lightbulb";
That gets me yesterday’s notes, and I can do the same with today, but I’m not sure what expression I should use for notes that have been modified in the past three days, say. Help most welcome.
And a bonus question: I’m assuming the badge would be removed if the note is no longer caught by this Agent, or am I wrong? If so, what would be a better way?
Good, but to nudge to in the right direction and whilst the above may work (the app can be forgiving in that respect, that query is more correctly—and informatively—written as:
$Modified==date("yesterday")
That explicitly tells Tinderbox that you want Date-type data for the day resolved by the date designatoryesterday. Note too that for Date-type data, the time element of the date is ignored for ==, !=, <= and >= (see more).
So, you want to find notes modified on or since three days previous to today. Putting the above facts together, you need some date arithmetic:
$Modified>=date("today - 3 days")
Thus if, as I write this it is 19 Jul, then running the latter code (above) today would match notes modified on or since 16 July. Run tomorrow it would match 17 July or later, etc. Note that by its nature $Modified can never be later than ‘now’ so filtering future dates are not a problem here.
I’m bound to ask what makes you assume that? You’ve told Tinderbox to set a badge if a certain query is matched. A query can’t affect notes it doesn’t match and a note with a lightbulb badge with a modification date a week ago can’t match your queries above.
There are two approaches to the second task. Firstly an agent to find all lightbulb-badged notes whose $Modified is over 3 days old and an action to set the badge to default. So the query is:
Note we check the $Badge value first as that results in fewer matches feeding into the second term - a more efficient process than testing $Modified first. Now the action:
$Badge=;
This resets the affected notes’ badges to the documents default.
A second approach would be to use a rule, edict or stamp; for my an edict seems the right level of frequency. In all cases the code is:
I’m not sure what made me assume the $Badge would be removed, it’s a good point (and a neat solution). I guess it was because during some abortive trial runs the lightbulb appeared to disappear, so I thought the lightbulb was an attribute only attached to the alias, or else it behaved like NL tags, where updates to the text of a note force a change in the NL tags assigned to it (as I understand it.) Clearly that’s not the case.
Thanks. $Badge is a bit of text metadata - a String-type attribute. If it holds a valid (case-sensitive) text string that matches the name of a badge icon, that icon is shown. IOW, unless we the user write code to do so $Badge never changes.
In this context, the comparison with NL tags is incorrect. In the latter case, there is code running (to set/unset tag values) but it is an encapsulated task the user can’t control. Note too, that the Tagger process is controlled so it doesn’t run too often lest it affect other processes that need to run.
Generally, you want to acquire the habit of not checking everything all the time as it is easy. That generally has no effect in a play/test document but when lots of such processes are running they may interact—even if only by competing for resource—in ways we did not intent.
Generally, as in the agent example above scope queries so each term (if several) lessens the number passed to the next query term. If the conditions for some setting need a complex query, it may be useful to mark affected notes with a user Boolean attribute, i.e. set true if a note meets the criteria. The it is easy to test one boolean attribute rather than a complex query to get the same result. This is a process of abstraction that will become natural if you start to use action code a lot. It might seem unintuitive at start but it is but enlightened self-interest. Your future, more experienced, self will thank you.
Tinderbox offers many ways to do things; here’s another.
As you know, your agent has an OnAdd action, which you’re using to set the badge.
Agents also have an OnRemove button, performed when a note that formerly satisfied the agent’s query no longer does so. So, you could set the badge in OnAdd and reset it in OnRemove.
As a general rule, if you have a bunch of actions that set a bunch of different $Badges (or flags, or some other property), I find it’s often clearer to set things up as Mark Anderson did, with explicit actions driving the value for every case. Are we late? Then wave the red flag. If not, are we new? If not, are we recent? OK: do we involve Headquarters? No? Is Personnel involved? No? Is a transaction >€10,000 potentially involved? No? Then remove the badge!
