Hi Thomas,

On Tue, 30 Dec 2003, Thomas DeWeese wrote:

>     There is an attribute in the AttributedString associated with
> a TextNode called TEXT_COMPOUND_DELIMITER.  This is a reference
> to the Element that generated that character in the AttributedString
> (see runLimit on attributed string).

        Oooh, excellent!  Thank you. :-)  Sounds like what I was looking
for.


>     There is a decent chance that I may change this attribute to
> be a SoftReference to the element.

        If I may ask: why?

        * As long as the DOM Document exists, the Element will exist.

        * As long as the Bridge exists, the DOM Document will exist.

        * Thus, in practice with an SVGComponent, there will always be a
          strong-reference to the Element, so using a SoftReference will
          accomplish nothing.  In addition, there will be the added overhead
          of having the SoftReference object itself.

        Or if I'm wrong and it is possible for all the strong-references to
        disappear, then the availability of that Element becomes
        non-deterministic.  And, theoretically (though I doubt it'd ever
        show up in practice), anyone attempting to use that through the
        SoftReference could create a race condition if the VM decided it was
        time to clear SoftReferences between when the TextNode was created
        and when someone tried to grab that Element.  This could be even
        more unpleasant if threads are involved (which they frequently are
        with Batik, if I remember right).

> > Am I barking up the wrong tree?  Should I be watching for DOM events
> > instead?
>
>     I would tend to lean this way.  If you want to manipulate the DOM
> using the DOM events is almost always the way to go.  It
> automatically does the above handling for you.

        I'll keep that in mind.  Thanks. :-)

        I'd also be perfectly content to modify the TextNode directly, as
long as they DOM stayed synchronized with the changes.  From what I've seen
in this list's archives, though, it sounds like the best/easiest way to keep
them synchronized is to mess with only the DOM.

        The reason I'm mucking around with both the DOM and the GVT tree is
because I'm doing much of the work using Interactors.  The reason I'm doing
things with Interactors (which has proven cumbersome as complexity
increased) is because I needed to be able to recieve events even if the user
clicked in an area of the SVGCanvas which did not contain part of the SVG.
I think I tried many things, including putting even listeners on the
CanvasGraphicsNode, to no avail, and finally went this route.

        Looking back, I could just have tossed a full-size rectangle (maybe
even a transparent rectangle) as the first SVGElement in the DOM after
loading it, and taken it out when saving, which would have allowed me to get
the events I needed and allowed me to use GVTEvents / DOMEvents.  Maybe if I
get time, I'll rewrite things in this cleaner manner; but I'm on a schedule
now.  (and maybe there are other possibilities I didn't try... *shrug* it's
been a while; I can't even remember what I /did/ try ;-).

> > Any help would be greatly appreciated.
> >
> > Thanks!
> >
> > - Bibek


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to