Problem with Prototype Operation

I need diagnosis and remedy advice on prototype operation.

  1. I set up a container to hold notes on a series of reports from a common archival source.
  2. I gave the common source container a number of key attributes and made it a prototype. I applied to a proper on-add action command.
  3. For the first 40 reports or so, I operated in map view. Each of the notes worked properly, identifying the prototype correctly and displaying the key attributes properly.
  4. Then I switched to outline view because the number of reports was too large to manage on my screen.
  5. Now I find that new notes placed in the container show the correct prototype in the properties inspector but do not display the key attributes of the prototype.

Please advise.

If a note already has key attributes assigned, either manually or by an action, then it wonā€™t inherit $KeyAttributes; thatā€™s the way inheritance works.

Perhaps youā€™re assigning an explicit key attributes? Map vs outline is very unlikely to be a factor in this.

Given the last point above, try resetting the $Keyttributes first in your OnAdd action. Letā€™s assume the ONAdd action is currently:

$Prototype="pReportNote":

Change it to:

$Keyttributes=;$Prototype="pReportNote":

This resets any existing key attribute setup before setting the prototype and thus ensuring the notes inherit the prototypeā€™s key attributes.

1 Like

Unfortunately the remedy does not work. This is only the most recent difficulty I have encountered with TBX. I appreciate the power and potential of the software. However, I now regret having spent too much money and time trying to make it serve my rather simple needs. I am abandoning ship and moving back to older, more primitive methods that do not require so much operational maintenance.

Thank you for your replies to my query.

Given the effort thus far, donā€™t give up too easily. Do you have a version of the file we can see (i.e. a URL to a demo showing the problem). The sort of issue you raised can be hard to diagnose from description alone because, from experience, the causal factor has been (unwittingly) omitted from the description of the problem.

Anyway, Iā€™m happy to take a look at the file (or a version of it that shows the problem) if it helps. Donā€™t give up too easily. :slight_smile:

Thank you for your kind offer. However, over the course of the night I have broken the file apart (if that is the right terminology), removing all container, prototype, and inheritance relationships. I plan to try once more to re-create a simple container, source, note hierarchy without any OnAdd actions (or actions of any kind for that matter). There are days when one is tempted to return to 3 x 5 cards.

FWIW, if you have Time Machine running, you might be able to get at an old copy of the file. My hunch is the ā€˜errorā€™ is in fact the unexpected results of some overlooked experimentation; this is because Iā€™ve never known a prototype to fail in the way described. Trying to guess the cause isnā€™t possible from the data at hand and a list of guesses would be a trial to write - and to read!

One way to experiment with Action code with less automation is to place your code into a Stamp. When applied, a stamp is run once only on the selected itemā€” or each each selected item if more than one. This can make it easier to see if the outcome of the code is as expected, before placing it in more automated contexts like an OnAdd.

I think I may have found one possible cause of your glitch if a note has the same title ($Name) as a prototype, or your have two prototypes the same, odd results may occur. I suspect this is what happened in your case.

Tinderbox does allow two notes of the same name. It also allows two prototypes of the same name or a same-named pair of prototype and normal note. However, testing just now in the latter two cases off effects can occur (I gave each note/prototype a different set of key attributes). In such a scenario Tinderbox can have a problem figuring our which of the same-named notes it the source prototype.bIā€™m not sure if that is what hit you but it is a possibility. TL;DR - if unsure of detail always give prototype notes a unique name. A common method is to use a prefix so the prototype has a name youā€™d never likely use for a normal content note, thus ā€œpNoteā€ or ā€œ_noteā€ or ā€œ*noteā€, etc., rather than ā€œnoteā€.

Footnote. For historical reasons Tinderbox built-in prototypes donā€™t use such an approach. 10+ years back the app was a lot simpler and such accidents were less likely. Changing the prototypesā€™ names now would, likely break someoneā€™s code that had worked for years, or at least their use of such prototypes.

1 Like

Many thanks for your thoughtful assistance. I have a working file without the OnAdd actions and the (apparently) dysfunctional prototype. I have never used a Stamp, but will do so now. My leap to OnAdd was a bridge too far.