To change an attribute by clicking a note


I would like to create “buttons” in my Tinderbox file. By buttons, I mean notes which change an attribute when I click on them.
Someone mentioned $OnVisit which sounds like one could realise my dream with it. However, I cannot make it to work.


Also, what does “to visit a note” mean? To select it?


PS. I know I could make $Checked become a displayed attribute and make it work via selecting the note and clicking the checkmark (two clicks). Selecting a note and hitting the key to quickstamp works as well (click + keyboard shortcut). Can we go even further?

You’ll use $OnVist just like you would a $Rule, $Edict, $OnRemove, etc., so you’d do something like this;

It would be a on-time action on visit.

1 Like

Thank you, Michael.
I like your way of testing it via displayed attribute pane. This means one less obstacle for me thinking what brackets I should be using in the formula. I will try to remove the checked status somehow so that the button is “clickable” again.
Or will try to find other solution to make it an action which is not doable just one time.

First: if you want to use buttons right away, you might think about joining the backstage programs Tinderbox: Tinderbox Backstage, since recent experimental builds have some nice new support.

OnVisit runs when the note is selected.

Another good way to test things like buttons is to set the note’s color, or BorderColor, or Badge.

if($Color=="white"){$Color="black"} else {$Color=white;}

Another way to see the effect right away!

I’m not sure where you got that syntax from, but it is not valid in Tinderbox. Also, I’m not 100% sure this is intended use of $OnVisit. Still, $OnVistis is an Action-type attribute and expects to hold one or more complete action code expressions. The action (expression) you are trying to use is:


So, how do we make sure that the contents of $OnVisit is the above? We need to supply the whole expression a a single string to store in $OnVisit. As the content we want already uses double quotes, we need to demarcate the string value we want with matched single quotes, like so:

$OnVisit = '$Checked="true";';

†. It is actually there for Storyspace compatibility. so if it works it works, but don’t be surprised if it doesn’t—in event terms—work as you presume.

‡. Tinderbox generally uses double quotes by default for string delimiters. But either may be used interchangeable—as long as both open and close are the same type. The may also be nested, as above, as long as both pairs match, i.e. outer pair are the same and inner pair are the same.

Excellent, thank you. I was trying to play with undoing the change with the time attribute relative to “now” if $Chekced is, well, checked. Hm, on the other hand, the aforementioned method with “if” requires to click away from the note.

(…) since recent experimental builds have some nice new support.


To be a fully fledged button, the note would need to behave differently though. Currently, when I use $OnVisit, the note is selected and clicking it again will do the standard things like changing the name, etc. Which is totally fine and intuitive, however a button should allow to click on it multiple times. Let’s say a button to add venues in your great example on planning an event.

A key modifier used when clicking (visiting) a note perhaps? Or a way to lock a note (like locking adornments) so that when one clicks on it, it is not selected, thus becoming a clickable being doing something.

Sorry, just thinking out loud here.

I could swear that I saw “$OnVisit[]” in Tinderbox’s Command and Functions. I checked it again and there are no brackets at all. My bad again.

Yes. But, by way of managing expectations, Tinderbox maps are not a form of programmable UI with user-designed dialogs, etc. That’s simply not part of its aim. There are lots of programmable database that I think are far better suited to the data input task. For my 2¢ as a long-term user, ‘just’ adding all that extra UI support to Tinderbox would not benefit the app as a whole.

I am not a designer nor a programmer. However, in my experience having additional options (not forcing every user to do something specific way, just optional alternatives) is generally a positive thing. There is also something like a feature bloat which I also don’t prefer in software.

But I guess this conversation digressed a bit too too much from the main subject. I am happy we have this discussion though.