>> 1. Swing event triggers canvas.setSVGDocument(firstDoc). >> >> 2. manipulate firstDoc's DOM (in UpdateManger's thread) in response to >> Swing mouse clicks, etc. >> >> 3. Swing event calls canvas.getSVGDocument() to get the modified >> firstDoc back, and then canvas.setSVGDocument(secondDoc). > > > Hi George, > > So are we OK up to here?
Yes.
> Well a stack trace would have helped to identify why you get the > NPE. But my assumption is that you are modifying the firstDoc > before the UpdateManager that has been managing it is shut down.
I agree, it's because I am modifying the DOM outside of the UpdateManager's thread. Here's a stack trace.
java.lang.NullPointerException
at org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown Source)
at org.apache.batik.bridge.AbstractGraphicsNodeBridge.getDisplay(Unknown Source)
at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
at org.apache.batik.bridge.SVGGElementBridge.handleElementAdded(Unknown Source)
at org.apache.batik.bridge.SVGGElementBridge.handleDOMNodeInsertedEvent(Unknown Source)
at org.apache.batik.bridge.BridgeContext$DOMNodeInsertedEventListener.handleEvent(Unknown Source)
at org.apache.batik.dom.events.EventSupport.fireEventListeners(Unknown Source)
at org.apache.batik.dom.events.EventSupport.dispatchEvent(Unknown Source)
at org.apache.batik.dom.AbstractNode.dispatchEvent(Unknown Source)
at org.apache.batik.dom.AbstractParentNode.fireDOMNodeInsertedEvent(Unknown Source)
at org.apache.batik.dom.AbstractParentNode.appendChild(Unknown Source)
at edu.rutgers.elearning.util.SVGUtils.newScribbleGroup(SVGUtils.java:87)
at edu.rutgers.elearning.scribble.ScribbleComponent.addScribbleGroup(ScribbleComponent.java:968)
at edu.rutgers.elearning.presenter.Presenter.saveCurrentSlide(Presenter.java:903)
at edu.rutgers.elearning.presenter.Presenter.displaySlide(Presenter.java:1020)
at edu.rutgers.elearning.presenter.Presenter.access$400(Presenter.java:79)
at edu.rutgers.elearning.presenter.Presenter$14.actionPerformed(Presenter.java:617)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1786)
at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1839)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
at com.sun.java.swing.plaf.gtk.SynthButtonListener.mouseReleased(SynthButtonListener.java:250)
at java.awt.Component.processMouseEvent(Component.java:5100)
at java.awt.Component.processEvent(Component.java:4897)
at java.awt.Container.processEvent(Container.java:1569)
at java.awt.Component.dispatchEventImpl(Component.java:3615)
at java.awt.Container.dispatchEventImpl(Container.java:1627)
at java.awt.Component.dispatchEvent(Component.java:3477)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:3483)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3198)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3128)
at java.awt.Container.dispatchEventImpl(Container.java:1613)
at java.awt.Window.dispatchEventImpl(Window.java:1606)
at java.awt.Component.dispatchEvent(Component.java:3477)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:456)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
> There is a set of UpdateManagerEvents that you can listen to, in > order to know when it has shut down.
Which thread are the UpdateManagerEvents fired in? The javadoc documentation implies that they run in Swing. Which means I'd deadlock if I blocked waiting for them, since my event is also running in the Swing thread. Unless I spawned a new thread for each Swing event, which is kind of a mess.
> It isn't clear to me why you are modifying the firstDoc's DOM when > it isn't being displayed or why going to the next SVG Document would > cause problems with 'previous' documents.
Well I place an SVG doc into the canvas, let the user modify it, and then unload it (actually, load a new doc.) Then I modify the (unloaded) doc to adjust some of the settings before saving the XML to a file. The modifications after unload are just the logic of my app; nothing that needs to be displayed. The trouble seems to stem from the fact that I'm not properly waiting for the doc to be "unloaded" from the canvas.
> Well it sounds to me like you need to queue these user events until > the system can catch up with them. I would suggest using something > like our RunnableQueue to do this.
Yeah, this is what I am afraid of. It would really complicate things to propagate the "queueness" of the canvas to the rest of our app. I'm trying to isolate all of the batik event handling to my canvas extension, and keep it as much a black box as possible. We need synchronous behavior for the rest of the app (load the doc, modify it, unload it, install next doc.)
> The first thing the runnable does is check that the canvas is > 'stable' (Which can block because we are out of the Swing thread) > then it can install the next document.
Ah, so maybe the UpdateManager's events are not fired from the Swing thread after all?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
