Exception in CControl.write(File)

Byte-Welt - Projekte / Projects DockingFrames-Bugs
1

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)

2

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 :wink:

Thanks for the bug report, I can always use such information.

3

Switching to XML worked fine :slight_smile:

Thanks again for the quick reply.

4

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).

5

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.

6

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:

  1. Start application
  2. Move Dockables MSP8+MSP9 to Area Test3, AllTrades1+AllTrades2 to Area Test2 and OwnTrades1+AllTradesOfToday1 to Area Test1
  3. Save layout (layout1.xml)
  4. Restart application and load layout => everything is fine
  5. Save layout without changing anything (layout2.xml)
  6. 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.

7

Hm, you have an application to your excellent step-by-step description? … would make testing a lot easier :stuck_out_tongue:

8

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.

9

Hi Beni,

the problem was caused by our own code - we did register the dockables, but our initialization sequence was wrong elsewhere :confused:

10

I think I have to write some logger or debugging tool in the future, that would help to find such problems much faster :slight_smile: