Edict code to turn container note red if $DueDate>date("now")?

Agents, Actions and Automation
1

I would like to use some edict code on a container note to simply turn it red IF any child notes have an overdue $DueDate
Seems simple, but I cannot seem to make it work.

Edict code I have tried:

if($DueDate(children)>date(“now”)){$Color=“bright red”}

Obviously wrong. it turns my container note red with any note irregardless of the $DueDate.

Here is my sample sandboxed tbx.

Thanks in advance
Tom

OverDueContainerTest.tbx (85.3 KB)

2

Thanks for the test file - I’ll upload an edited version with my solution at the end of this post.

$DueDate(children) gets us a list of dates which you can’t compare en masse without another operator. You want to test if any child is overdue. Not sure if there’s an op for that. Go to the aTbRef action code listing or the sitemap and get your browser to search a the word ‘any’ and you’ll find the any() operator.

The operator’s task—as with its every() counterpart— is to collect a set of note references, test the condition of an action code expression such as a particular attributes value. For any() the operator is true if even a single tested note matches the test, while every() is true only if all items in the tested group match the test.

So, as you correctly guessed in your code above, the grouping we want to test is children. Now what test do we run? You hunch was correct: $DueDate<date("now")†. Using any() lets us run that test on each item in the list we collected.

I tested this code:

if(any(children,$DueDate<date("today"))){
   $Color="red";
}else{
   $Color=;
};

which give you the solution I believe you are describing.

In this edited TBX, I’ve put the edict code in a stamp called “Simulate Edict”. The code executes in the same manner but a stamp will only fire once, when the user presses the button. This can be useful for developing edicts (and, more so, rules) as you don’t want to fire of a half-baked code by pressing return too early.

See: OverDueContainerTest1.tbx (78.6 KB). Try the stamp out. Then copy the stamp’s code to the container’s edict and test again.

So, you were close. Your oversight was not to follow through on the ‘any’ aspect which you had correctly stated in your opening question. Although pure query terms like .contains() can test against a list, tests like yours above generally need a different operator specifically designed to test discretely every list item.

Does that help? Hopefully, you’ve got a solution but as pertinently some idea of where your own initial attempt came unstuck.

†. I see you used the “now” time designator and I “used” today, but it so happens they both resolve at code level to the same test value so there are interchangeable.

2 Likes
3

Many thanks MarkA. It worked perfectly! I had never used the any() operator before…I am not sure why I have not. My AHA today, it is now so obvious the many instances where any() can be used. Thank you for the great explanation!

On another note, to everyone else, here is an example where I was stuck in trying to write a portion of code. I looked at aTBRef, tried a few times on my own, then asked the forum a specific question I was trying to solve. I included with a test Example.tbx to make it easy for anyone to test.

I then moved on with my work knowing I would come back to it later. In the past, I would spend countless hours with code I did not understand or even know about.

Afterward, I write a note in my own words explaining the gap, what I have learned, where I can apply this next time and the person who helped me for reference. For anyone learning tinderbox code, this process along with the commitment to using Tinderbox daily has accelerated my learning.

Thanks to all in the forum. I could not have made it without your help.
Tom

1 Like
4

Great feedback, and thanks. Two really positive points from your first step:

  • You articulated the question in a way that described the logic rather than merely the outcome. That’s a pivotal learning step for this sort of app, in my experience.
  • You made a really useful small test doc.

Not all scenarios allow for such leanness as in the last step. But, another learning experience I’d share from my own path to learning how to use Tinderbox is that sometimes just the act of making a test doc to share with/explain to others is enough to shake free the last pieces of the puzzle. This might seem counter-intuitive at first encounter. But, it is (unintentionally) an exercise in abstraction: “what pieces do I need to showcase the problem?”. All too often we’re trying to fix a problem/learn a new technique amidst the noise of a doc containing everything we’re working on.

Even today, if I’m in a real project and I’ve had a nibble at a problem and had no success, I’ll start a new doc and add pieces of the puzzle and (incremental formalism) burrow my way into the problem. In a toolbox app—as opposed to (more commonly) an optimised-workflow app—there is no one right solution and as importantly the ‘problem’ isn’t where/what we thought it was.

1 Like
5

Lastly, you thankfully mentioned that any() and every() were related/similar in some ways. How are they different? To me, I think of using every() in a loop variable and any() more in a finding sort of way. Am I close?
(I need more work using loop variables…I do not fully grasp it yet, but that is another matter)

Thanks
Tom

6

Wow…you are so right on here. So many times, getting clarity involves understanding and simplifying the question you are trying to ask.

Tom

7

Happily it’s quite simple (no that’s not a jibe at you!) once we peel back the layers. Both any() and every() take two arguments:

  • a group of things. It might be as easily defined as by a single group designator (e.g. ‘children’) or as convoluted as a find() (which is essentially a nested agent-type query)—all the left-handed Nobel laureates who’ve visited Paris or some such definable but non-simple thread in your own data.
  • value, which can be restated as an action code expressions that resolves to a true/false answer.

The value test is applied, separately, to each item in group and the true or false outcome is recorded. This lets us answer three questions:

  1. do all items match the test? (i.e. every item returns true)
  2. do only some items match the test? (i.e. at least on item returns true)
  3. do no items match the test? (i.e. all are false)

every() tests #1 and #3. any() test for #2 and #3. It’s as simple—or complex :slight_smile: —as that!

Does that help? Do ask if not. I know from my own Tinderbox learning that not everything is obvious until after the fact.

1 Like
8

Tom, this is a good exercise. Go check out this video and example file: Tinderbox Training Video 26 - Daily Journal Time Tracking Project Management Part 1.

You’ll find a ton of operations to support exactly this type of behavior.

2 Likes
10

Thanks Michael, will head there next. Thankful to both of you.

Tom