Hi,
I encountered the following exception sometimes, but still don’t know what caused it. When the exception happened, my application crashed. I cannot reproduce the problem,and it probably would be not easy for you to provide a solution. I report the exception and hope maybe you could help this. Anyway, thanks for everything to make DockingFrames better.
Exception in thread “AWT-EventQueue-0” java.lang.NullPointerException
at bibliothek.gui.dock.SplitDockStation.paintOverlay(SplitDockStation.java:2755)
at bibliothek.gui.dock.station.OverpaintablePanel$Overlay.paintComponent(OverpaintablePanel.java:284)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintChildren(Unknown Source)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JLayeredPane.paint(Unknown Source)
at javax.swing.JComponent.paintToOffscreen(Unknown Source)
at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(Unknown Source)
at javax.swing.RepaintManager$PaintManager.paint(Unknown Source)
at javax.swing.BufferStrategyPaintManager.paint(Unknown Source)
at javax.swing.RepaintManager.paint(Unknown Source)
at javax.swing.JComponent._paintImmediately(Unknown Source)
at javax.swing.JComponent.paintImmediately(Unknown Source)
at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.prePaintDirtyRegions(Unknown Source)
at javax.swing.RepaintManager.access$700(Unknown Source)
at javax.swing.RepaintManager$ProcessingRunnable.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$400(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.awt.EventQueue$2.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Which version are you using? The line number in SplitDockStation and the method name do not match, and it seems that SplitDockStation has not changed for quite a while…
The dividerStrategy can not be ‘null’, because it is a private variable that seems to be initialized in the declaration and never changed - thus, it must return ‘null’ in getValue. If you are calling “setDividerStrategy(null)” somewhere, this might be the reason, although it should revert to the default behavior then (and not return null) - but that’s just a guess. Let’s wait until Beni had a look at this.
The result of dividerStrategy.getValue() can be null if the SplitDockStation is not attached to a DockController.
Many classes in this framework require a DockController to properly work. Usually the DockController is set before painting anything - but I guess in your case it is not. While I can (and will) add a little null-check in the paintOverlay-method, it would also be interesting to know why your SplitDockStation is painted without an attached controller. I can only guess, but things that have happened include:
multi-threading issue: your are changing the layout from a thread that is not the Event-Dispatch-Thread (EDT).
using SplitDockStation as a Dockable, and drag and drop them in a strange way. With “a strange way” I mean things like nesting them, or use some custom made code.
corrupt layouts, e.g. because there is another exception when loading and applying a layout. Or you were using the perspective API and somehow created a layout that is missing some parts.
things like creating many instances of DockControllers or SplitDockStations and mixing them randomly
Since I do not remember ever seeing an exception at that place, I am guessing that your application does something funny. Is there any chance to have a look at it?
Anyway, I will upload a version with a null-check at that location (at the time you read this, the update is probably already online). But that only hides the issue, it does not explain it.
I played around with the application, but the exception never happened. Then I looked at the source code, but it looks fine to me.
The only issue I found was this WindowAdapter (DockingLayer line 123) which first destroys the controller, and then continues to use it to save a layout. That should be the other way around. If you would continue to use your JFrame after calling „controller.destroy“ (I mean, if it remains visible on the screen, or is made visible again), then you would have exactly the Exception you described - and the Exception could be reproduced. But somehow looking at your code I guess you are not doing silly mistakes like that.
Sorry, I really cannot tell what happened or how to fix it
The only thing I can suggest right now is to let the application run in a debugger, set a breakpoint listening for the NullPointerException. And when it happens the next time, find out what the user was doing. Have a look at the station that throws the exception, e.g. find out which one it is (does it have „parent“?), find out if it is attached to a DockController (see the „controller“ field), find out what children it has (field „dockables“). Maybe that could help to reproduce the error.
Also version 1.1.2p10f has now a null-check that will prevent this exception.
