Having mastered a number of TB idioms I’m stumped on this one and need your help. The usage case concerns a basic diary with notes taken throughout the day or at least once at the end of the day. I use the $MyDate variable to keep track of the time of the event(s) I’m describing.
In some cases I can write at the moment of the event so my approach is to copy automatically the $Created intrinsic attribute of each note into $MyDate. If I’m writing about something that happened much earlier I simply correct the time or date manually.
Unfortunately I find I cannot copy $Created the way I thought. An example using QuickStamp is illustrated below. Each time I push apply on the QuickStamp the $MyDate is indeed updated but to the current time and NOT the creation time of the note which remains constant.
I believe that quickstamp doesn’t evaluate expressions, so you are just assigning nonsense to MyDate (since the string “$Created” isn’t a valid date), which seems to fall back on the current time as the default value that quickstamp assigns.
Create a stamp with the action $MyDate = $Created, and that should do what you want.
In that screenshot you are looking at the Action of the Test note, which corresponds to Test’s $OnAdd attribute. This will have no effect on Test itself, but will be applied to any note that becomes a child of Test.
To create a stamp with the action you need, go to Stamps -> Inspect Stamps… and create a new stamp. When you apply it to Test, it will set $MyDate to $Created as you want.
Notice that the On Add for Notes assigns the (modified) Event prototype to new children of Notes. The Set MyDate to Created stamp is found in the Stamps menu and behaves as suggested.
The point above is one it took me a while to internalize: that Stamps, and QuickStamps, despite their apparent similarity, are quite different things.
Operational lesson: it’s almost always worth creating a “real” Stamp. That’s because: a Stamp can include a sequence of actions; it can evaluate expressions; and (probably most important) it can be stored so it’s always available for, yes, “quick” use. QuickStamps aren’t saved in the same way.
For instance, in this case, you could create a Stamp with the action $MyDate=$Created. Then you assign that stamp a keystroke shortcut, via the Apple menu, or something like Keyboard Maestro. Then, whenever you want to make this date transformation, you just select the note in question and hit the shortcut key – Cmd-8 or whatever you’ve set up.
Also be aware of something implied in the preceding discussions. Two similar (in fact identical) terms, Action when you are creating or editing a Stamp, and Action in the Inspector for a note, mean different things.
The Action that you create with the Stamp Inspector, as shown with the red highlights below, is the sequence of commands that will take effect on notes you have selected and to which you apply that stamp.
That’s the “action” portion of a Stamp. The Action that you create for any specific note, will apply only to newly created child notes of that specific note. If it does not have any children, the Action has no effect. Any children already there before the Action is created will not be affected by it.
So: Stamps, and QuickStamps can both be quick, but they work in different ways.
And the Action in the stamp inspector, and the Action in the normal-note inspector, have underlying similarities but also important differences.
Paul and James - thanks for the wonderful and very clear summaries. They hit the nail on the head in terms of dispelling some lingering confusion on my side re. stamp menus and actions.
A suggestion: It would be worth updating the TBRef description of Quickstamps with a sentence or two on the difference between QuickStamp and Stamps building on the discussion above to guide future users of this functions.
Also just a quick note to avert possible confusion: Setting the Action of a note with the Action Inspector sets the note’s $OnAdd attribute; setting the Action of an agent with the Action Inspector sets the agent’s $AgentAction attribute.
Excellent point, thanks. So there are three working implications of Action – all of which are similar (and different from QuickStamps) in being able to evaluate expressions and to include a sequence of specific actions (separated by semicolons), but which apply in different circumstances and have the different attribute names mentioned above:
The action for a Stamp applies only to notes you have selected, and then applied the stamp to;
The action for a normal Note applies only to new child items of the note, when you add them to the note (making it a container-note) . Thus it is an on-add action (with its complement, the on-remove action).
The action for an Agent note applies to the aliases of notes that meet the agent’s selection criteria.
And a forth: the action for an Adornment (corresponding to its $OnAdd attribute), which applies to notes that are brought onto the adornment (these will always be siblings of the adornment — adornments cannot have children).
Agents also support an $OnRemove action, which is quite handy: it’s a rule that fires as soon as a note stops matching the agent’s query. You can use this, for example, to create an “Urgent Tasks” agent, whose action colors matched notes red, but whose $OnRemove action colors them gray.
I’m drafting an article for aTbRef re actions/stamps/quickstamps. A few corrections/clarifications to recent posts above:
Notes and adornments have both an OnAdd and OnRemove. The action fires once per note added to or created in the container (sidenote: I don’t think it’s possible to manually add a new not within the confines of an adornment. Meh.). As OnRemove only arrived in v6, many older articles/tutorials now incorrectly state there is no ‘remove’ action. If you see the latter, look at the publication date of the article.
Agents do support OnRemove. In this case the action runs once on the alias of the note (q.v. intrinsic attributes)
If a selection includes both notes and agents setting code in the ‘Action’ sub-tab of the action Inspector will result in setting the value of $OnAdd for notes and $AgentAction for agents. Neat!
Although you could manually set $OnAdd for an agent or $AgentAction for a note, in neither case will that code get called.
Quickstamp is something I suspect you either use a lot of not at all as it’s simply a way to set the value of a single selected attribute. It’s value over adding the same in Get Info or as a Key Attribute is that a QuickStamp acts once on every selected item whereas Get Info and KA are per note.
My belief is QuickStamp is intended for literal values and not evaluated action code ( @eastgate might want to correct me on that).
Currently an adornment’s $OnRemove will only fire if a note is dragged off the adornment. If it is pulled off the adornment by another adornment’s query, or pushed off the adornment by the adornment’s query not matching it, $OnRemove will not fire. I believe this is a bug, and I’ve reported it to @eastgate, but I haven’t heard back about it yet.
Just did some testing, and an adornment’s $OnRemove also doesn’t fire if you manually set $XPos or $YPos so that the note jumps off the adornment. It seems like it only works with dragging.
That would make sense as if a note doesn’t meed a smart adornment’s query it has to be moved (by the app not user) which presumably means changing those notes’ $Xpos and $Ypos values. Interesting possible edge case: can’t remember if query-gathered notes overflow the adornment if many notes and small adornment size. If so, then a query-rejected item might already lie outside the existing adornment bounds thus complicating the remove test if only done by checking if a note is currently ‘on’ the adornment.
