Returning to Tinderbox, and unearthing my old TBX files circa 2007-13. The simpler ones run well in TBX 11.8, but the main one for my book is complex, and has issues.
Currently, it will launch in 11.8, and the poking around I’ve done hasn’t caused any crashes or hangs. It does open two copies of itself, and when quit and then re-opened, will only trigger the creation of a new outline. I can replace the current file with a fresh copy of my archived version, and things repeat themselves: it’ll run, but only that once.
So two questions:
. Is there some sort of log file that’s readable that might tell what TBX 11.8 is objecting to?
. What’s the procedure for opening a file with automatic update shut off? It seems you can’t uncheck automatic update before opening the file?
Of course, if some expert knows what the solution is, I’d be grateful to hear it.
Note also that I’m not hoping to get the file fully operative; I have no intention of updating or continuing use. My interest is in reading it as a TBX source document. I didn’t really document how I programmed it, and 12 years later have no real recollection of all the functionality it contains.
If the original was pre-v6, then every note of note window will open a a full document window, you can lose all except one as port of tidying up. 2014 was around when v6 came out but many may still have been using a late version of v5. You may well have legacy agent query code. Although deprecated by the time of v5, #-prefixed codes were still allowed (see).
In short, no, not in terms of some log file in the app support folder.
The automatic updates (i.e. the agent cycle) setting is stored in the TBX as a preference. In the XML you are looking for a line:
<AutomaticAgentUpdate > 1</AutomaticAgentUpdate>
You need to set the 1 value to 0 (zero) save the XML file and then re-open the TBX.
But even so all agents are evaluated on start-up so if you’ve old unsupported query code so now ‘bad’ code, this might cause a fail.
And inspect the code between the tags for outdated code. The " must have used for any double-qoutes (") as that can’t be stored verbatim in XML values.
As @mwra wrote upstream, I assume that the “two copies of itself” are two windows, corresponding to the multiple open windows used in Tinderbox 5 and earlier.
I don’t understand what you mean by “trigger the creation of a new outline.” Could you elaborate slightly?
There isn’t one. I doubt automatic agent updates are causing trouble here.
Oh, I’m confident we can resolve this in short order. Can you send me a copy of the original antique file?
It had occurred to me that I could shut off the Auto-update by editing the XML. It makes no difference, confirming M. Bernstein’s assertion.
What I meant by “trigger the creation of a new outline” is that with the successful initial open of the 14.2Mb TBX file, one window is marked as edited. Before close, it seems there’s no way to “unmark” the editing, so I’m not sure whether it’s saved with changes or not. (I realize I can check this.) The file size at this point is still 14.2Mb. If I re-open the file in TBX, I’m greeted with “Untitled File 2,” ie a file with none of my data. If I save that file, the resultant file size in below 100Kb, or much smaller than 14.2 Mb in any event.
I extracted 56 AgentQueries from the TBX XML. I’ll pursue M. Anderson’s suggestion of reading the queries for bad code; reading code is what I wanted to do anyway.
If there’s still an issue frustrating my review, I’d value your offer to examine the file for issues.
However, as I noted, the auto-update doesn’t stop all agents/rules/edicts running at least once on document load. An app choking query would thus still get run regardless of auto-update state.
I’m not asserting agents re the (only) problem but just correcting the misconception that auto-update being ‘off’ stops agents getting run at all.
OK: that’s diagnostic. There’s a string, probably in $Text, that has an encoding error, Early Tinderbox was lenient, but that was wrong. Send me the file, we’ll find the bad character, and then this will be resolved.
Oh, sorry! I wasn’t aware. I did mail it to info@eastgate.com, but if you’re unable to access it there, I’ll send another copy when I’m back home. Thanks!
The problem turned out to be a single character in a single pdf import from (IIRC) 2011. We did things differently then; this would not have cause problems today. It’s fixed in the coming backstage build (b811).
