George Armhold wrote:
Yes and no. There is logic in the rest of our app that expects to get
the "old" document back from the canvas and "do stuff" with it. Of
course we can install callbacks that are fired when the doc is really
unloaded, but our code is quickly turning into a tangled mess of such
callbacks. But if I must, I must. :-)
This tends to be the nature of GUI programs, they can almost never
be implemented as clean procedural code.
Thomas DeWeese wrote:
>> final Document oldDoc = canvas.getSVGDocument();
>> final UpdateManager um = canavs.getUpdateManager();
>> um.addUpdateManagerListener(new UpdateManagerAdapter() {
>> public void managerStopped(UpdateManagerEvent e) {
>> um.removeUpdateManagerListener(this);
>> prepDocument(oldDoc);
>> writeDocument(oldDoc);
>> }
>> };
>> canvas.setSVGDocument(newDoc);
> Hmm, there is a problem with this. The BridgeContext isn't disposed
> of until after all the managerStopped Listeners have been called. I
> don't think this is correct behavior, but until it's fixed you will
> actually have to hang your listener off the document load or gvt
> build listener to make sure the old document is no longer 'active'.
You mean I should install this listener after (say) gvtBuildCompleted?
No I meant you will need to use the gvtBuildCompleted event to
know that your oldDoc is 100% disentangled from the Canvas. You should
probably also catch the build failed (problem with doc), and build canceled events
as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
