I need diagnosis and remedy advice on prototype operation.
I set up a container to hold notes on a series of reports from a common archival source.
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.
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.
Then I switched to outline view because the number of reports was too large to manage on my screen.
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.
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.
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.
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.
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.
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.