Hi Romain,
Romain CATTEAU <[email protected]> wrote on 04/10/2009 09:12:26 AM:
> In that picture, you can notice a floodgate symbol in the background (it
> appears in black). We have added some SVG content to show that the
floodgate
> is opened. That additional content is made up of a :
> - a red triangle (path element),
> - a text : "17.1 0". That text is made up 2 text spans : "17.1" and "0".
> We then try to hide the text span "17.1" by setting the value of its
display
> element to none. We also modify the dx attribute so as to center the
text
> "0"
> As you can see, the behavior is a little bit strange. What we see is a
> combination of the target view "0" in the center and of the previous
view
> ("17.1 O").
I've never seen this sort of behavior before.
> However, the SVGDocument seems to be correct. We write the content of
the
> SVGDocument to a SVG file each time a modification is performed. Here is
the
> corresponding part of the SVG file :
There is something a little odd, both of the tspan's
have display="none". How are you saving your document?
> <g id="TMa255a744-0b63-42aa-abf9-4c6823ecc28a">
> <g id="TM59" transform="translate(427.53 ,208.3) rotate(0)">
> <path fill="rgb(160,0,0)" stroke-width="0.2" d="M-5.5,-3 L5.5,-3 L5.5,3
z"
> stroke="rgb(160,0,0)"/>
> <text style="text-anchor: middle; font-size: 3.3; fill: rgb(160,0,0)"
> id="TMTEXT59" transform="translate(0,11.0) scale(1,-1)">
> <tspan display="none">17.1</tspan>
> <tspan dx="0" display="none">O</tspan>
> </text>
> </g>
> </g>
>
> Moreover, everything's ok when we load the document in squiggle
> (SQUIGGLE_VIEW.png)
> http://www.nabble.com/file/p22987781/SQUIGGLE_VIEW.png SQUIGGLE_VIEW.png
This isn't necessarily a good test because improperly set attributes
can be 'fixed' by round tripping through a file (particularly namespace
issues).
> Everything happens as if there were several GraphicsNode instances for
the
> text Element the id of which id "TMTEXT59"
> In fact, we can detect events for each element. We can click on the text
> element corresponding to the "previous view" ("17.1 O") and we can also
> click on the text element corresponding to the target view ("0"). In
both
> cases, the id of the Element is the same : "TMTEXT59".
Is the Element the same? I.E. if you print the Object you get is the
object 'pointer' the same in both cases?
> Has somebody ever met such a strange situation?
My suspicion is that your update code is somehow creating multiple
instances of the text element. Can you create a standalone test case?
