Hi Marco,
I think your current method should work (unless of course the document isn't
dynamic in which case it may never have an UpdateManager). You might also
consider listening to the onload event (either on the document using DOM
events, or you can register an SVGLoadEventDispatcherListener with the canvas
directly.
However without knowing your application at all I wonder if possibly the
problem isn't listening to early but listening too late, i.e. you request the
UpdateManager after it has been discarded (which might happen if you dispose of
the document shortly after it has finished rendering).
Thomas
On Nov 2, 2012, at 9:53 AM, Marco Herrn <m...@mherrn.de> wrote:
> Hi,
>
> I must push this mail again.
> It now happened again multiple times to me, that the the method
> canvas.getUpdataManager() returned null when the gvgTreeRenderer completed.
> It happens seldom, but it does happen.
>
> Please see again the code snipped in the quoted text.
>
> Is it a bug in batik? According to the javadoc of the getUpdateManager()
> method I would expect that it is guaranteed that getUpdateManager() won't
> return null when being called after being informed of rendering completion.
>
> Any help appreciated.
> Regards
> Marco
>
>
> On Fri, Jul 20, 2012 at 03:38:45PM +0200, m...@mherrn.de wrote:
>> Hi I am using the following code:
>>
>> canvas.addGVTTreeRendererListener(new GVTTreeRendererAdapter() {
>> @Override
>> public void gvtRenderingCompleted(GVTTreeRendererEvent e) {
>>
>> canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
>> }
>> });
>>
>> to do some changes in the DOM of an SVG document. I expected that the
>> updatemanager is definitely available when gvtRenderingCompleted was
>> called.
>> However, it now happened at least once that I got a NullPointerException
>> on the line
>> canvas.getUpdateManager().getUpdateRunnableQueue().invokeLater(runnable);
>>
>> So it seems that there is still no guarantee that the UpdateManager is
>> available then. Am I missing something? Must I register on a different
>> listener?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
