I got the following exception when calling CControl.write(File) in the latest 1.1.0 version. The same call worked fine in 1.0.8.
Exception in thread “AWT-EventQueue-0” java.lang.NullPointerException
at java.io.DataOutputStream.writeUTF(Unknown Source)
at java.io.DataOutputStream.writeUTF(Unknown Source)
at bibliothek.gui.dock.common.intern.CommonSingleDockableFactory.write(Unknown Source)
at bibliothek.gui.dock.common.intern.CommonSingleDockableFactory.write(Unknown Source)
at bibliothek.gui.dock.layout.PredefinedDockSituation$PreloadFactory.write(Unknown Source)
at bibliothek.gui.dock.layout.PredefinedDockSituation$PreloadFactory.write(Unknown Source)
at bibliothek.gui.dock.layout.DockSituation.writeCompositionStream(Unknown Source)
at bibliothek.gui.dock.layout.DockSituation.writeCompositionStream(Unknown Source)
at bibliothek.gui.dock.layout.DockSituation.writeComposition(Unknown Source)
at bibliothek.gui.dock.frontend.Setting.write(Unknown Source)
at bibliothek.gui.dock.common.intern.CSetting.write(Unknown Source)
at bibliothek.gui.DockFrontend.write(Unknown Source)
at bibliothek.gui.DockFrontend.write(Unknown Source)
at bibliothek.gui.dock.common.CControl$8.write(Unknown Source)
at bibliothek.gui.dock.support.util.ApplicationResourceManager.writeStream(Unknown Source)
at bibliothek.gui.dock.support.util.ApplicationResourceManager.writeFile(Unknown Source)
at bibliothek.gui.dock.common.CControl.write(Unknown Source)
Ups, I’m sure I know what is happening. There was only a small change in the format, and that is causing the exception. I’ll upload a repaired version within a week.
Hm, you seem to be one of the few people who does not use XML, otherwise this bug would have been found a lot earlier
Thanks for the bug report, I can always use such information.
This seems to be no bug, but anyhow I am wondering why this happens …
If I start the attached test program, drag the dockable “XXX” to the primary frame and close the second frame which results in the call “control.removeContentArea(contentArea2)”, this content area is still be listed as root for dockable “XXX” in the layout file generated by writeXML(File).
For each Dockable there is a history of the places where it was (one entry per ExtendedMode - minimized, maximized, etc…). And the entry you see is part of that history. In your current layout this entry is already obsolete, and the next time XXX is moved it will be overriden.
I am afraid I have encountered another problem while saving and restoring layouts. Here is a step-by-step description together with the resulting layout XML files:
Start application
Move Dockables MSP8+MSP9 to Area Test3, AllTrades1+AllTrades2 to Area Test2 and OwnTrades1+AllTradesOfToday1 to Area Test1
Save layout (layout1.xml)
Restart application and load layout => everything is fine
Save layout without changing anything (layout2.xml)
Restart application and load layout => Areas Test1+Test2 are empty, the four dockables which should appear there are not visible at all
I would assume that layout1.xml and layout2.xml should be identical except the historical layout information described above. This is not the case.
Just something you can check quickly: are all Dockables (or SingleCDockableFactories) registered before you load the layout? Because the framework silently ignores missing Dockables. That would be an easy explanation for this issue.
