Maik Schürer wrote:
Thanks Kai and Thomas,
t.addEventListener("SVGZoom", new OnZoomAction(), false);
and
JGVTComponentListener.componentTransformChanged()
both works fine for me
but I would prefer EventListener "SVGZoom" because JGVTComponentListener ist
also raised after pan and rotate.
Or should I use JGVTComponentListener ? (because of performance or other
reasons)
I would choose based on what I was trying to do. If I was
doing 'swing' things I would use the Component Listener (since
it is called in the Swing thread), if it was DOM things I would
use the DOM method since it is called in the UpdateManager Thread.
If it really didn't matter then I would probably use the DOM
because as I said they are standard and hence much less likely
to change.
As to performance they will be similar. You can filter the
changes by using the code from JSVGComponent.JSVGComponentListener
which is what dispatches the DOM zoom event.
Maik
----- Original Message -----
From: "Thomas DeWeese" <[EMAIL PROTECTED]>
To: "Batik Users" <[EMAIL PROTECTED]>
Sent: Wednesday, December 01, 2004 11:50 AM
Subject: Re: how to catch resize events in JSVGCanvas via shift + right
mouse key
Hi Maik,
Maik Schürer wrote:
up to now I catch resize events in JSVGCanvas with a ComponentListener.
But it only works when the canvas (window) changes its size ....
Meves, gave a good answer to this using the DOM, which is
definitely the preferred solution as the DOM interfaces are standard).
There also exists an extension to the ComponentListener interface
called the JGVTComponentListener which adds componentTransformChanged
which is what the zoom event it built off of internally.
Additional I want to catch events, when I change my SVG view via shift +
right mouse key + move (fast zoom in/out).
Ho can I do this ?
There is no public interface for this. The only solution would
be to subclass either the canvas so you get events when the 'paint
transform' changes as well, or the AbstractImageZoomInteractor so it
notifies you or does the work directly.
Incidentally this indicates why the DOM is preferred. Now that
you mention this I'm tempted to add either a new method to the
JGVTComponentListener to track paint changes or perhaps a new
event type (COMPONENT_PAINT_TRANSFORM_CHANGED). Which could break
existing code (or at least cause the code to be called much more
than expected).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
