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
Later,
Andreas
