If more and more tools popup here - like the wonderful Logger by @echuck it may become more useful to store those code snippets in external text files to reuse them in different TBX files without having to copy&paste them several time and for each new version again and again. And you could use the great Codeless Language Module from @Pete
It’s very easy to use this technique - take a look into the readme of the demo file I attach.
ExternalSourceDemo.zip (43.3 KB)
A useful thing we as a user community can do is to make page(s) in the File Exchange part of the forum pointing to useful files/posts such as above. The caveat will be that unless the creators update the files, the continual evolution of the app may affect use.
But I think that’s always been true. As I write, I’m just working on a file I mentioned at the meet-up. It dates from c.4.x and all sorts of things have changed such that what looks like a simple brush-up has actually been a lot of work - in hindsight I should have stated over.
A further thought in the light of the above, it is probably useful to note in then-current Tinderbox version used to make the doc. hat might help someone months or years latter to figure out how/where no-current behaviour has diverged since. Assuming a resource like aTbRef (and the previous baseline versions of it) are around it should possible to figure out relevant app feature changes in the interim.
Simple case in point. a doc from 4.x, opens in v9. But every window (pre-v6 design was somewhat different) opens as a document window which is confusing. Maps will look as fonts have changed, Colour defaults have changed, the size/rendering of notes has changed. None of that is a show-stopper but means some interpretation is needed.
The same is true of action and export code behaviours. For example, pre v5 Sets had a ~ toggle add/remove operators. That was removed in v5 and the were no changes up until v8. But, in v9 Sets the notion of Sets always re-sorting themselves was enforced. Hitherto, it was a risk you took. A Set, as Lists only arrived in v5) might resort from the input order but generally didn’t, From v5 if sort persistence mattered more than deduping, we used a list, else a Set. In v5.9.2, we got List.unique making this choice less painful.
Sorry for the long explanation but i think it helps explain the suggestion at opening.
Again, I really appreciate all the creative/innovative solutions you and others have come up with for working with Tinderbox documents. I have much to learn from you and other prolific community contributors.
I should note that I’ve been a BBEdit user since the early '90s (we’re talking classic Macintosh system software version 6 at that time), so I can see lots of benefits to using BBEdit as a complementary tool to Tinderbox, and I already do use it to help shape data structures I want to import into Tinderbox.
However, that said, I am interested in exploring some different approaches now that Tinderbox 9.1 has provided a very useful enhancement with callable functions. In particular, with the logging Toolbox, I am experimenting with a complete applet package. Specifically, a Tinderbox document that combines functions with stamps and other Action code plus any prototypes, notes, containers, and user attributes necessary to provide a complete workable solution. In addition, I favor including the documentation for the applet/tool/utility in the Tinderbox document package. Isolating Action code in separate files outside of Tinderbox is counter to this approach, though something that may be useful during the development phase.
As we noted over in the Logging for fun and profit posting, the importing of user attributes is still a bit tricky, and something to be addressed in a more definitive manner. However, my sense is that taking a complete package approach has the potential to be more useful to the broader base of Tinderbox users.
Hi Chuck, I don’t want to argue against your wise speech. But using external code doesn’t affect the way your TBX solution works in any way - as far as I can tell. The code will be copied into regular notes and regular attributes and works - after importing the text - like any other action code.
What I like with the external files is the better option to share the stuff in the community and to reuse the code in different TBX files. But it is just one way to go 
I would love to see your applet in a saturday meeting!
If I recall this has been raised as a feature request for exactly the reason you mention. Though things like drag-drop data import (OPML, CSV, etc.) will do their best to generate appropriately (named if not always typed) attributes from header rows (CSV/TSV) or OPML element attributes, when copy pasting notes with action code (function, stamps, rules, etc.) the same does not occur (yet!)
I think part of the scaffolding is in place with the attribute() Dictionary.
@mwra—Thank you for confirming my impression that this is a recognized issue that Eastgate is well aware of, and likely working on a solution. I anticipate that we’ll see a workable solution in a new Tinderbox version, which will be the best way to address this need.
In the meantime, I’m experimenting with some approaches to manually address this problem. When I think I’ve got something that works adequately, I will update the original posting to provide guidance on how users can deal with the four user attributes required for the logging tools.
I am trying to keep things a simple as possible.
In the short-term AppleScript can provide the glue. How and where that script is invoked is an open question but it can be done. Users employ a range of helpers (Keyboard Maestro, Alfred, etc.) but I don’t thing there is one everyone uses so a script that could be placed in the user’s files and then called via runCommand() seems a logical (interim) approach.