Create a stamp for toggling links - links visibility respectively

I would like to create a stamp that allows for toggling the visibility of links in a map.

How would I do that?

Do you need to have lots of different link types? If not, you could make a new linkType, hidden, that is invisible. After that, you’ll need a function that changes all the untitled links on a given note to have type have type hidden, and another to make all the hidden links *untitled. We might call those hideLinks(path:string){} and showLinks(path:string).

Finally, we want functions that take a list of paths and call show and hide in turn for each path.


OK: when I started this reply I was ready to say, “you can’t.” Half-way through, I was ready to say, “this is awfully complicated.” But it’s not, not really! The basic idea is simply an outline of what you want:

  1. For each note theNode in this container…
  2. For each link theLink starting or ending on theNode…
  3. Set the type of the link to hidden or *untitled

If I were doing this, I’d do it in very small steps — steps so small that nothing could possibly go wrong — and check at each step that nothing is, in fact, going wrong. I’d do everything in functions, and try to limit each function to a handful of lines.

If you DO need lots of link types, then save the old link type in a dictionary attribute and restore it when unhiding. But that’s making things really painful, at least if you have multiple links from the same note with distinct paths. At that point, my recommendation might be: ask Mark to add a new action.

1 Like

OK, I’ve implemented part of this in a single function. All three arguments are needed, but if supplied as an empty string value, a default is used. For the new/old link types it is *untitled and for the IDString is is this. Some of the tests also need a link type called hidden. Add a new link type to your document, call it “hidden” and un-tick the ‘visible’ label (you can leave the label option as invisible links don’t draw their label). The function is:

function fSwitchLink(iOldType:string, iNewType:string, iIDStr:string){

	var:string vNote;

	var:string vOldType;

	var:string vNewType;



To change the selected note’s untitled links to ‘hidden’ (using the optional empty defaults):


To change the selected note’s ‘agree’ links to ‘disagree’ (using the optional empty defaults):


By giving the $IDString of a different note, either as a literal string value or using an offset reference, e.g. $IDString(“Some note”), links for a different note can be altered.

Note that you can only toggle the link type of a pair of types, rather than all types. If you be easy to write a function to loop trough all used link types (we can get those from the link-types key of document(). Harder is storing original per-link differing link types, especially if the same two notes are linked by links of multiple types. IOW, I suggest the latter scenerio is not noew to plan for.

Anyway, here is the test doc for the above: linktype-swap.tbx (268.6 KB)

The TBX has 6 stamps (3 matched reversing pairs) for you to try out by switching to the Map view tab, selecting note ‘aa’ and applying a stamp.

Note that this method works by changing a given links link type and not the links properties. Individual links links cannot be altered using action code (though appleScript is a possibility, though i’ve not tested this).

However, I’m not sure the above is what @andreas was asking for. Instead I think he wanted a map-scoped single toggle for all link types (links and stubs). That basically alters the visible property of links as opposed to altering the link type of links. On a busy map there may be a lot of links and rather than fiddle with each, if there were a boolean switch that was checked at the point where the map starts to draw links I suspect that—whilst requiring a new feature (a system boolean?)—it might when done result in less work for the app to ‘just’ suppress links on a given map. FWIW, this sort of approach was what was in mind when i mentioned it when describing a circular map layout pattern the other day (see this thread).

OK. I’m working on better control for link visibility. Should be backstage in a day or two.

1 Like

thank you @mwra

I am afraid, though, I don’t get it

that would be of great help. thanks

Well, it’s a demo code that does what you ask, within the limits of the current app. You can ‘hide’ all links. You can change any/all links to a different type that is configured to not be visible (here in the Links Inspector):

The code posted does that, so that you don’t have to do the task manually in the Browse Links dialog. Swapping one link type, e.g. ‘*untitled’ to a ‘hidden’ type is easy, as demonstrated. Cyling through easy link type in use and changing it to hidden … (oops pressed wrong button, continued in next post).

… is pretty easy do do, building off my demo above. Storing each link’s existing link is much harder. Of the per-link properties revealed via eachLink only source, destination, and type are read-write the rest being read-only, so we can’t save the normal, visible, link type.

So that’s what you can do now. For Backstage members a more nuanced control is already under test.

Great1 @mwra

1 Like

Now I start to get it @mwra … and eventually could benefit from your kind “template”.

The only way I see right now to toggle more than one “untitled” Link to “hidden” is by selecting all nots on the map and then apply the respective stamp. Is that correct?

1 Like

You could select one note in the map.

Then, loop through all the children of that note’s parents.

The probelm with the above and multiple link ytypes is knowing to which link type to toggle back to. Links do have a comment field but it is read-only in action code. so changing all links to a ‘hidden’ type is easy, changing back is difficult.

For now it’s probably easier to open the Links Inspector and simply alter visibility fo currently used link types. Even so you’ll need to record or remember which those are for when you wish them to be visible again.

It’s hard to give a simple answer because there are several different reasons/contexts for wanting invisible links:

  1. Some links are used structurally or only for automation so should be seen. Possible. Turn off visibility for those link types only in the Links Inspector.
  2. The user doesn’t want to see any links at all. Possible. Turn off visibility for every link type in the Links Inspector.
  3. Visible links in some maps but not others. Possible with a lot of manual effort - use Browse Links for each note and untick visibility for each link text/basic link (weblinks never draw lines). for links populating inbound stubs, these settings have to be done in the links source note. A lot of work if many links. An action-code based solution is being trialled (Backstage users only) so may become available but not as at v9.5.2.
  4. Temporary/quick on/off toggle for the current map. Though a slightly different cause, the outcome is as for #3 above. A menu based visibility toggle has been raised here but not, I think, formally suggested.

The nuance between the latter and the solution being trialled. is that the latter uses action code to toggle the visibility of some/all links (depending how code is used). The latter idea is one where the user tells Tinderbox "Stop drawing all links, regardless of their visibility state). Extensive testing in recent days suggests to me there is no one-size-fits-all answer as all the above scenarios are both entirely likely but different.

In fact, you already see the effect of #1 in a doc using prototypes. Yes, because prototype assignments are reflected by a link of type ‘prototype’ form the prototype to the note using it but the link is default set to not be visible. Aside, and in case anyone wonders, a lot of action code link-related operators auto-exclude prototype links as generally the user is not expecting such a relationship to be a link.

1 Like

Ack. I had the backstage solution in mind

… which of course only raises the appetite to see the backstage discussed solution go live eventually. Really looking forward to this.

1 Like

Thank you ever so much, @mwra, for always supporting and pushing our understanding!

1 Like