Tinderbox Forum

Using covid() to update $Text

I would like to use the covid() operator to update the $Text of a note. I have tried using using both a stamp and a rule with the following syntax:

$Text = covid(“02148”, date(4,1,2020), “cases”);

I believe the covid() call is returning “nothing” because I can add my own text to $Text and it is wiped out by the above call.

Is the covid() operator currently working? I’m on 8.7.0 (b464).

I think perhaps this would work better:

$Text = $Text + covid('02148", date(4,1,2020), "cases");

This would ensure that the end of your $Text, though any previous returns of the covid() operator. the latter has some limitation, for instance as someone in the UK, aI can only get US data. That’s not a complaint, just making the point about reading the documentation (as I write this I believe the linked page is correct).

Pulling back a bit there are two separate thinks to test here:

  • Is covid() returning data? Try this in a small doc and if you get output the system works.
  • Is my manual input destroying the Covid() input or vice versa. The code you’d described sets, or rather deletes existing $Text and sets, $Text to the output of the supplied covid() call. If you manually edit the note in that circumstance you may add to the text (before/after/instead of the existing text) but at the next agent cycle the existing $Text will be replaced by your rule’s output.

Pulling back again, assuming covid() is returning a value, what were you assuming the outcome to be. You can’t use inline replacement in $Text, i.e. inserting dynamic values (or it’s certasinly not a n intentionally offered feature). However if you put this inline in text:

^value(covid(........))^

and viewed the note text through the text pane Preview tab, you might see the inline value you expected.

Thank you for the help, Mark. Below are the things I’ve tried without success:

Preview
Tried Preview using template value statement in the text of my note:

Cases: ^value(covid('02148", date(4,1,2020), "cases”))^

Assign to User Number Attribute
I created an attribute Cases with type ‘number’ on my note. I created a stamp with the following code:

$Cases = covid('02148", date(4,1,2020), "cases");

Assign to User String Attribute
I created an attribute CasesString with type ‘string’ on my note. I created a stamp with the following code:

$CasesString = covid('02148", date(4,1,2020), "cases");

Is this a re-keying error, or are the quote types actually differing/ You open with a single and close with a double, which will cause an issue for code parsing.

:man_facepalming: I made that mistake in my TBX file. Thank you for pointing that out.

Now in the Apple Console I can see lots of activity from boringssl_*. So, things are happening under the covers. However, I’m still not getting any values set using the (corrected) methods mentioned previously.

Attached is my test file

.CovidTest.tbx.zip (20.5 KB)

OK, you had the inputs for the type of date(y, m, d, h, m) you were using in reverse order. Plus, some of the quotes were in typographic (‘curly’) form—doubtless due to ‘smart quotes’ coercions.

Tip: if working on action code in a note, first add the built-in prototype “Code” and set your note to use that prototype before adding any $Text. The prototype turns of both smart quotes and smarts dashes (i.e. two hyphens become an en-dash, etc.)

Also, from testing, I don’t think you can use covid() directly in an action. In stead, I gave the note an edict:

$MyString=covid("02148", date(2020,5,1), "cases");

Then in the note $Text I used text:

Cases: ^value($MyString)^

But, in truth it might be easier to simply show $MyString as a Key Attributes and read the COVID data there.

THANK YOU @mwra!! These are awesome tips and much appreciated! It is now working brilliantly.

NOW, for the bad news. The order of the date arguments is incorrect in the documentation. :grinning:

Thank you again!

Oops, I copied the example code from the release notes without checking (I did my tests with different code). Still, I should have spotted the error! Sorry for the confusion caused. The article is now fixed.