It would be great if one could turn on a "debug mode", which would display a log of each activity that TBX has done and one what items. This could also include a "failed to parse action" message or some such.

I've found the hardest thing about developing TBX repositories has been debugging actions and rules. When I screw up the syntax of something, TBX silently ignores it.

The option of making TBX squeal would be nice.

@Mark - so helpful, hope you will put into the reference document, with even more tips if possible. Perhaps others have ideas as well? I'm not sure I can add much. I do some of the things you mention, but this is a weakness in my own 'game' ...

Yes, in writing the answer I was thinking this out to be an aTbRef article (if not in the manual too). As regards aTbRef, it won't be for a couple of weeks though as I'm busy tinkering with that doc so won't be adding any new pages in the interim.

I should add that I wish I was as diligent in applying the above techniques as my comments might make it appear. The irony is that it's so easy to dive into quite complex things in TB that one also all too easily moves quickly past the point of realising "Ah, I ought to make some modular tests, before using my live data.". However, the worst penance for that error is usually only frustration. Most care needs to be taken when synching with other systems or using complex cascading actions. The latter, especially are worth testing on a deliberate testbed and/or a copy of real data before using your real live data. As with much in life you generally find the correct point for shifting to a deliberate test by getting it wrong … (at least) once.  

Saving notes like above?  Open your reference TBX, add a note and open it's text window. Now open the URL such as http://www.eastgate.com/Tinderbox/forum//YaBB.pl?num=1321833832/1#1(my notes upthread) in a web browser and drag the URL into the taxt pane. $URL is set and displayed as a key attribute. Or just drag the URL into your main view (outline, map, etc.) and a new note is made for you with $URL set.  Or just use Yojimbo, DevonThink, etc. to store the URL.

Incidentally, from experimentation, the thread URL syntax is like this:

.....YaBB.pl?num=1321833832/1#1

The red is the UD for the thread.  Leave off the rest of the above after the ID and the thread opens at the opeing post.  Want to open the thread scrolled to answer #4? Just add the blue bit above, in this example '/4#4' after the UID. BTW, no idea why the post number's repeated, i.e. why it's /4#4 not /#4.

Good tip - thanks. I'd never tried that. I presume that if you always print the same source page (URL) the PDF's default saved name would be the same. If you always save such PDFs to the same folder then if the thread continues you can save a new PDF back over the old, as required, with no great extra effort.

Your suggestion of using this 'print' archive method strikes me as very useful. Some topics aren't generic enough to push on into general documentation. Nicely the 'print' data still maintains working URL links to other threads, specimen files, etc. Re linked demo files and such, I'd always suggest saving your own local copy of such files as their source URL may not live for ever.

Side note, for those who don't look at release notes, if you're re-reading saved solutions from months/years back it is well worth checking that the app hasn't fixed/improved the issue since the original thread.

Last night I came up with a "Tinderbox way" to help with debugging.

Why not include two new system attributes, say ParseOK and ParseError. The first would be a Boolean whose value indicates whether the last action on this note succeeded. The second would say something abut why it failed, if it failed. For example, $ParseOK==0 and $ParseError=="missing expected semicolon, you silly git" would save me hours and hours of debugging time.