I track my weight every day in my Tinderbox daybook file. While my current method of doing this is not a burden, I’d still like to know if it’s possible to improve it.
I have a container: Weight Log. Its Action sets a Prototype of children to pWeightLogEntry and the current date. The prototype is simple. It shows a couple of Key Attributes and has a Display Expression something like “Weight was $Weight on $Date”.
What I’d like to happen is to hit Return to create a new pWeightLogEntry, type my weight as the $Name, hit return again, and have the user attribute “Weight” populated automatically. Is this possible without having to create a separate agent to handle it? This is similar to the “Run Once” technique I used to use, but I was wondering if I’m missing something simpler.
This really only needs to happen once per note, upon creation, and no more than once a day, so edicts and agents seem like overkill. Of course, it’s super easy to just do this manually, but I’m mostly just curious to know if this sort of thing is possible.
Personally, I’d do something like this. I’d use $OnAdd to set the note name to today, and set the measurement date to today. I’d then use a display expression to show the weight in the name and average it on the container. Creating a note, adding the weight to the name and then having it parse out seems like a whole lot of extra steps.
The only entry you’d need to do is enter the weight in the attribute.
I never thought of averaging the weight at the container. Good idea!
I’m not sure I’m with you about the extra steps, though. Your suggestion is similar to what I’m doing now. It involves creating a note, then editing the Weight attribute. There’s extra mouse and keyboard work involved there :). My wish is to create a note, type the weight, and hit return.
It’s less about saving keystrokes and more about finding a way to parse the Name of a new note immediately upon saving. Saving the $Name to $Weight is one example, but I can imagine other uses such as parsing #hashtags in the name, etc. Something like an OnCreate or OnEdit event.
This could also be useful for my earlier question about where and when to run a function that sets an attribute based on a note’s length. The calculations only need to be run once after an edit, maybe after the note loses focus. That’s it. A repeatedly running rule or edict shouldn’t be necessary, should they? I don’t know of another way to do this. It’s possible I’m just overthinking it or approaching it wrong. With Tinderbox there’s almost always a way
And by the way, Michael, your videos have been very helpful. Thanks for those!
One thing that threw me initially was that turning off the Rule as part of the Prototype’s Rule would make this a non-starter since it would cause the rule to be disabled on notes based on the Prototype. I started to add a conditional around $IsPrototype, but it seems to work fine without it. Perhaps Rules don’t run on Prototypes?
One thing that initially confused me was that turning off the Rule as part of the Prototype’s Rule would make this a non-starter because it would disable the rule on notes based on the Prototype. I attempted to add a conditional around $IsPrototype, but it appears to work just fine without it. Maybe Rules don’t work on Prototypes?
Rules will work on a prototype, actually that is why this option is here. Disabling enabling the rule on a prototype will ensure the rule does not run on the prototype but will let it run on the other notes.
$RuleDisabled is an intrinsic attribute: it’s not inherited, and every note has its own value. There are a handful of intrinsic attributes. Others include Xpos, Ypos, Width, Height, and things like $Container.
I was talking with @mwra this morning, had an idea and he pointed me in the right direction.
If you use the $Pattern feature, you can use the map view to plot and visualize the weight changes. The line is the target weight.
I also added a $Change attribute to calculate weight change by looking at the next sibling from a reverse sorted date list (take a look at the $Edict).
NOTE: I removed the disabled rule for now. On faster machines, this seems to be terminating the existing rule before ehte name change can take effect. Mark B. is looking into it. Will report back.
Interesting. I haven’t run into that yet on a new MBP M1 Pro Max but will keep an eye on it. You may already know this, but your R3 example document is showing what looks like a syntax error on the container’s $OnAdd. (I’ve not tried debugging it, sorry).
