Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
Tinderbox Users >> Agent, Actions, Rules & Automation >> Explosive problem.

Message started by Alastair on Jul 10th, 2012, 11:15am

Title: Explosive problem.
Post by Alastair on Jul 10th, 2012, 11:15am

Afternoon, quick problem:

I'm trying to explode a long document (an NBS specification) into nested chapters, sections and clauses.  I know that there's no automated explode in Tinderbox (+1 for that incidentally), so to try and speed this up I want to automatically assign prototypes to the resulting notes.  In theory, when exploding a note with a Chapter prototype I want the resulting notes to become Sections, children of a Section will become Clauses. Adding the code:

if($Name!="Exploded Text"){$Prototype="Section"};

to the OnAdd box of the Chapter prototype ought to produce a folder full of notes, and when these are dragged up and out of the 'Exploded Text' container they should all receive the new prototype. It doesn't - it changes the prototype of "Exploded Text". The following fails:

if!($Name=="Exploded Text"){$Prototype="Section"};

as does

if(!$Name(Exploded Text)){$Prototype="Section"};

All these rules set the prototype of the Exploded Text folder to "Section". Interestingly, the opposite approach:

if($Name=="Exploded Text"){$Prototype="Section"};

fails to set the prototype.

I realise that I could do this with agents instead, but I'd like to know what I'm doing wrong here. Something blindingly obvious I imagine..

Title: Re: Explosive problem.
Post by Mark Anderson on Jul 10th, 2012, 11:53am

Some specimen source text might make this easier - or even a small TBX showing where you start from post-explode.

I'm spinning my wheels trying to replicate this as I don't understand the logic.  You explode a note (satisfactorily). We know such an action always produces a child container called "Exploded Text" in which all the explode results are placed. Ah - are you adding code to the $OnAdd of the note being exploded? Such as:

if($Name!="Exploded Text"){$Prototype="Section"};

As the exploded notes are children of "Exploded Text", the prototype is never applied. I think you're probably meaning to do something like is:

if($Name=="Exploded Text"){$OnAdd='$Prototype="Section"'};

(Note the need to nest single/double quotes). However the above doesn't work. Testing by manually adding a child "Exploded Text" and then manually adding children to it, all works.  This implies, that the Explode process isn't firing the exploded note's $OnAdd.

If I recall the latter may be design as I seem to recall this was a safety measure after one or two over-adventurous souls got some runaway results tinkering with this sort of code approach. There is a way though.

Make an agent. The query is:

$Name(parent(original)) == "Exploded Text"

Action is:

if($Prototype(grandparent(original) == "Chapter"){$Prototype="Section"};
if($Prototype(grandparent(original) == "Section"){$Prototype="Clause"};

You can extend as needed. For instance, adding (not fully tested):

if($Prototype){$Container(original) = $Container(parent(original))}

Thus once a prototype is applied the exploded notes are moved up a level inside their correct parent. Another agent could look for empty "Exploded Text" containers and move then to a container elsewhere for later manual deletion. However, I'm not 100% certain if the latter might detect an explode in the process of being written.  If, as I'm guessing, the "Exploded Text" container is added with children already in place, you should be OK.

Title: Re: Explosive problem.
Post by Alastair on Jul 10th, 2012, 12:19pm

Sorry, didn't explain myself very well.  A sample tbx is at


The idea was to explode the note at the delimiter '<ch>', remove the delimiter and use the first line to title the note.  Then, the resulting notes would be dragged up one level, setting them to a 'Chapter' prototype.  In practice, it sets the $Prototype of the 'Exploded Text' folder, and I don't understand why.

Thanks for the alternative solution, I have worked round the problem using something similar - just want to know what I was doing wrong.

Title: Re: Explosive problem.
Post by Mark Anderson on Jul 10th, 2012, 1:40pm

Thanks. I can see you were using the code where I thought, though in a slightly different workflow. As it happens, I was able to follow your process and it all worked for me - I didn't get the problem you cited**.  After doing the Explode on the relevant delimiter (& deleting said string), I then used Shift+Tab to promote the relevant newly-exploded notes one level so as to be siblings of "Exploded Text" at which point they were set with the right prototype. I then simply deleted "Exploded Text" (and any unwanted Explode results within it) before selecting the first newly promoted note to Explode , etc., etc.

** to set the "Exploded Text" prototype, you'd need to move it out of its parent and back in again in order to fire the $OnAdd and you process - as described - doesn't seem to need that. Anyway, it now appears a moot point as you've found a way around.

Glad you've found a solution but otherwise I think my earlier suggestion should stand you in good stead.

Lest anyone wonder, it isn't possible to do a cascaded multi-level explode in one go. It's not possible insofar as it's a sophistication of the basic Explode feature that's not implemented.

Explode did get discussed at the Hamburg meet-up and I think the (existing) code is likely due for review so if you've more precise needs from the feature, I'd drop a line to support (info@eastgate.com) explaining what they are.

Title: Re: Explosive problem.
Post by Alastair on Jul 11th, 2012, 5:24am

Thanks for your help.

I'm still using 5.9.1, so possibly it's an issue that's been corrected since I last updated.  Will also drop a line to Eastgate about Explode, because it's something I find myself using a lot.


Title: Re: Explosive problem.
Post by Mark Anderson on Jul 11th, 2012, 7:49am

I just tested your file in v5.9.1, and:
- now understand your earlier description better
- can confirm the file works the same in v5.9.1 & v5.11.2
- release note #1865 (v4.7.1) no longer applies

Consider a note with 2 prototypes. Note 'Test' has its $OnAdd set to $Prototype="pRed". 'pRed' has the $OnAdd code $Prototype="pGreen"

The release note for v4.7.1 said:

The "Exploded Text" receives the same contents as the note which is being exploded, with the exception of OnAdd actions and Rules, which are no longer cloned from the original note.

I read that as saying, the 'Exploded Text' container is added to the outline without invoking its new parent's $OnAdd. Clearly, this isn't happening, as seen here in v5.9.1:

Incidentally, v5.11.2 does the same. Still, that's a good thing here as it's what you want - in terms of invoking $OnAdd via an Explode. But, it's not exactly what you want as your $OnAdd code says *don't* do anything if you're called "Exploded Text". Here's what I think happens:
  • Explode fires
  • The exploding note has a new child added, but untitled (no $Name).
  • The parent's $OnAdd fires.
  • The child is renamed "Exploded Text".
IOW, your code's test works correctly - it just can't do the test envisaged. so we're after a note with no $Name. In fact I tried testing your explode source with all these:


The first two work (well, they're syntax equivalents) as 'Exploded Text' now gets no prototype set. In the round though, all is not quite as desired (badges just help indicate intent):

Note that in Test #1 the 'Exploded Text' colour is correct as per the coding of the $OnAdd, though not the outcome we really desire. Note that we just can't achieve the same as the manually set results in the first container - where everything *except* 'Exploded Text' gets a prototype. Drag-drop and Crete-in-place won't play ball.

Clearly edit-in-place  & explode result in new notes but both don't fire $OnAdd as for drag-drop (or action code move) but neither to they interact with $OnAdd in the same way.

OK, well that was informative, if not ultimately helpful. As it is, I think the original issue is moot, because even if your TBX's code exploded a 'Spec' prototyped note such that 'Exploded Text' got a 'Chapter' prototype and its children were 'Section' prototype, the latter, on being shifted up a level fire the new parent's $OnAdd and become 'Chapter' prototype notes. Of course that process is harmless only if other code doesn't do things to the exploded notes during the short spell they are wrongly prototyped as 'Section'.

I return, therefore, to my earlier suggestion of backing off the automation to an agent, especially if you're doing this often (you can always turn the agent off when not needed and/or store it in a hidden corner of your outline).

Sorry for the long post, but I figure others may trip over the issue so this may be of use to a wider audience.

Title: Re: Explosive problem.
Post by Alastair on Jul 27th, 2012, 6:20am

Thanks (and apologies for the delay in replying), that does make sense.

Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com) » Powered by YaBB 2.2.1!
YaBB © 2000-2008. All Rights Reserved.