On Jun 8, 2006, at 14:30, Andreas L Delmelle wrote:

Some more follow-up on the problem WRT percentage resolution in markers:

<snip />
RetrieveMarkers are resolved in the parent's createChildLMs(), in iterating over the list of childNodes. Subsequently, the RetrieveMarker is unable to reparent the cloned subtree to its own parent, since this would lead to a ConcurrentModificationException...

It's probably going to be easier to get the percentage resolution to point to the RetrieveMarker's parent in case it encounters a RetrieveMarker.

I'm not so sure anymore which one of the two options will be easier...
Debugging further showed me that getBaseLength() is being called with the descendant of a Marker as parameter (the original one, not the clone ?)

So I dug deeper, as this behaviour seemed rather peculiar to me. It got even stranger as I put the breakpoints earlier. The layoutmanagers are created as they should: with the cloned marker descendants as their base FO. No problem so far. However, when you look at the code in Marker, a special subtype of PropertyList is created, and therein lies the problem, I think.

My suspicion that the percentage resolution is done purely via the FOs pointed to by the PropertyList turned out to be correct, and what I'm currently looking at is rather nasty... 8)

The PropertyLists stored in the marker are created based on the original FOs, which means, IIC that all LengthBases or instances of derived classes in that PropertyList get a reference to the original FO. Later on, when RetrieveMarker is resolved, the marker descendants are cloned and the clones are then bound to these PropertyLists (=Map descPLists in Marker.java). As a result, the percentage resolution tries to climb a tree of LMs that was never created (there is no LM corresponding to the original FO)

Took a while to track down. Now all we need is a clean solution... :/

To Be Continued



Reply via email to