Prototype glitch?

I’ve created a number of prototypes. Suppose I create a prototype named “proto:Test” and then I create a note named “Test Results.” Sometimes when I click the dropdown list to assign “proto:Test” to “Test Results,” a new prototype named “Test Results” is created and applied to “Test Results.” In addition, when I click on the dropdown list, this new prototype, “Test Results” is among the listed prototypes.

This doesn’t always happen so I don’t know how to replicate it. I have noticed though that it happens more frequently if I attempt to assign a prototype to multiple notes at the same time. Tinderbox chooses the name of one of the selected notes, creates a prototype using that name, and assigns that new prototype to all the selected notes.

Two things. I would like to prevent this behavior from happening and I would also like to remove these extraneous prototypes from my list of prototypes.
Incidentally, when I look at the IsPrototype attribute for “Test Results,” it is not checked. Since it is not checked, does that not mean that Tinderbox doesn’t recognize it as a prototype? If so, why is it still listed in the dropdown list of prototypes?

If it matters, I’m using High Sierra - Version 10.13.2.

Thanks.

Where is this drop-down list? What view are you using? Even better could you post a link to a TBX that shows this behaviour?

As Mark Anderson said above, it would help a lot to see the document in question.

My suspicions:

  • Beware of notes that have the same name as prototypes; if several notes share the same name, Tinderbox might be using a different note as the prototype from the one you expect. Prototypes ought to have unique names.
  • If that’s not the culprit, keep an eye out for agents and OnAdd actions that are setting the prototype.

When I select a note, in map view, at the bottom-right of the note there appears a “shadow” for want of a better description. When I click on ths “shadow” the list of available prototypes pops up.

The behavior is inconsistent and unpredictable.

I name all my prototypes with the prefix “proto:” to distinguish them from regular notes.

What confuses me is that the behavior occurs perhaps once in 25 attempts. I’m always taken by surprise whenever it happens.

I will doublecheck all my agents and OnAdd actions.

I believe you are referring to the Prototype tab; the shadow is entirely different, and appears in both selected and unselected notes.

When you click and hold the prototype tab, or when you right-click the prototype tab, a menu of prototypes appears. If this occurs only once in 25 attempts, something is very wrong with your Mac, with your mouse, or you have some malfunctioning third-party hack that is interfering with your Mac’s ability to handle mouse events.

Thanks for your input. I’ll keep an eye on it and report if I figure out what’s happening.

Another question. My list of prototypes in the prototype menu continues to grow with all the added extraneous prototypes. Is there a way to clear the menu of the unwanted prototypes?

Sure: select the notes that shouldn’t be prototypes, and tell Tinderbox they’re not prototypes! The Inspector’s the easiest tool for this, but you can make a stamp if you like.

Again: something you’re doing is setting these notes to be prototypes.

One way this can happen is if you have an OnAdd action to set a prototype and have several notes with the same name. Most recently, I had a prototype called “Email” with the path /Prototypes/Email and another container called “Email” at root level (path /Email). I had an on-add behavior in several places that executed $Prototype = “Email” and found that the /Email note was getting turned into a prototype and assigned as prototype to notes subject to the OnAdd rule.

Even if you go back to the unwanted prototype and switch off its prototype status, it gets switched back on when the OnAdd rule fires, at least in my experience. (I don’t claim to have tested thoroughly but this is my current working hypothesis.)

The solution I have adopted is to prefix all prototypes with some standard prefix. In my case I am using “p.” as the prefix.

Two things to bear in mind with this strategy:

  1. you need to revisit any code (queries, rules, actions) that reference the old prototype names and update them.

  2. there seems to be some automatic behavior around prototype assignment. I have noticed that dragging OmniFocus tasks into TB will assign the Task prototype and will install and use the Built-in task prototype if there is not already a matching prototype. This became apparent when I changed the name of my own Task prototype to p.Task. I am about to search the forum for references to this and start a separate thread about this if appropriate.

The last is is simple case of user error and not a glitch. The cause is using a non-unique note title ($Name) in an action rather then the full path ($Path). Where a only a title is supplied and there is more than one match to the names. Tinderbox will match the first matching $Name (as judged by $OutlineOrder).

In the case described (more than one ‘Email’ note) the code should use the code path.

As regards prototypes & naming, for my own user prototypes I use a ‘p’ prefix, e.g. “pTask”, specifically to avoid name collisions.

1 Like

Makes sense now that you point that out. For some reason I was thinking of Prototype as just the name, since that is what you see in the drop down. but see now that clearly it is a note and subject to the usual issues about uniqueness. Thank you for clarifying!

1 Like

Quick follow up: should

$Prototype |= “/Prototypes/Email”

work in the example above?

I tried prefixing the path in an OnAdd action and it does not seem to work. Shouldn’t be a problem as long as I use a prefix for prototypes.

When assigning to $Prototype, you must use a name, not a path, and so prototype names should be unique.

If you really want to do this, create a note with a known path that uses the prototype you want. We’ll call this exampleNote and put it in the container configuration. Then

$Prototype = $Prototype(/configuration/exampleNote).

That could be a really useful technique in that you could change prototype names and not break the code. Although I suppose changing prototype names would not happen that often. mainly doing it now to address the need for uniqueness.

1 Like