I’m finding that any dockable (connected and working in a CControl, sometimes visible, sometimes not) always returns null for its getBaseLocation(). Is this correct? Is there another way to get a CDockable’s CLocation?
With the current version (1.1.0p2) the result should not be null as long as the Dockable is visible and child of a properly registered CStation. You are using the factory methods of CControl to create a CContentArea (or other areas) or you are using the CControl.addStation-method? If not, that could be an explanation of the missing location.
You can also try and call “control.getLocationManager().getLocation( cdockable.intern() );” to get the location, or “control.getLocationManager().getCurrentMode( cdockable.intern() );” to check whether the extended-mode can be found (whether the item is maximized, normalized, …).
If nothing helps, then your code would be interesting.
I’m using 1.0.7 - I’ll try 1.1.0 - is this in release status?
I’m using the ‘built-in’ CContentArea of CControl, no addStation() or anything out of the ordinary.
At the moment, I use a CGrid to deploy the initial dockables (there are 5 of them). When it’s time to add a new dockable (through my own menu system), I use:
I do this because all existing dockables return null as their base location (I really wanted to use aside()). After the new one is added, and yet another is added, even the new one returns null (strange?).
One thing I’ve noticed is that I can add 3 new dockables ok - when I add a fourth new dockable, I get:
java.lang.NullPointerException
at bibliothek.gui.dock.common.location.CSplitLocation.expandProperty(Unknown Source)
at bibliothek.gui.dock.common.mode.station.CSplitDockStationHandle$Normal.getCLocation(Unknown Source)
at bibliothek.gui.dock.common.mode.CNormalMode.getCLocation(Unknown Source)
at bibliothek.gui.dock.common.mode.CLocationModeManager.getLocation(Unknown Source)
at bibliothek.gui.dock.common.intern.AbstractCDockable.getBaseLocation(Unknown Source)
at mesh.visualizer.CVisualizerPanel.actionPerformed(CVisualizerPanel.java:778)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:272)
at java.awt.Component.processMouseEvent(Component.java:6267)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6032)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4630)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4460)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
at ui.util.CGlobalHotkeyManager.dispatchEvent(CGlobalHotkeyManager.java:70)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
This looks like some internal positioning code is trying to get the base location and getting null.
I’ll have a go with 1.1 and see if it’s the same behaviour.
The API might change a bit when upgrading, but the preview versions of 1.1.0 are as stable as all the other versions. The best option I think is to try 1.1.0 before trying to figure out what is going wrong. After all even if you find a bug in 1.0.7 I wont fix it because I never fix the old versions.
[Edit: this at least works without exception and nulls. I would really need an application that compiles and runs for further testing.
import javax.swing.JFrame;
import bibliothek.gui.dock.common.CControl;
import bibliothek.gui.dock.common.CLocation;
import bibliothek.gui.dock.common.DefaultSingleCDockable;
import bibliothek.gui.dock.common.SingleCDockable;
public class Dock33 {
public static void main( String[] args ){
JFrame frame = new JFrame( "test" );
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
CControl control = new CControl( frame );
frame.add( control.getContentArea() );
SingleCDockable[] items = new SingleCDockable[5];
for( int i = 0; i < items.length; i++ ){
CLocation location = CLocation.base().normalSouth(0.3).east(0.3);
SingleCDockable dockable = new DefaultSingleCDockable( "i" + i );
items** = dockable;
control.addDockable( dockable );
dockable.setLocation( location );
dockable.setVisible( true );
}
for( SingleCDockable item : items ){
System.out.println( item.getBaseLocation() );
}
frame.setBounds( 0, 0, 500, 300 );
frame.setVisible( true );
}
}
Many thanks for your reply and test code.
When I run your code with the old version, it fails with NullPointerException.
With 1.1.0p2 - it works great!
So, whatever you’ve done between then and now, it’s fixed the null baseLocation() thing.
I’ve also been able to add any number of new dockables with no problems.
As an extra test, I used aside() for the new dockable’s location - perfect.