Problem moving DefaultSingleCDockable

Byte-Welt - Projekte / Projects DockingFrames
1

I’m using the following code to move a subclass of DefaultSingleCDockable

	tDockable.setStackable( true );
	tDockable.setExtendedMode( ExtendedMode.NORMALIZED  );
	DefaultCommonDockable dockable = tDockable.intern();

	DockController control = dockable.getController();
	DirectRemoteRelocator relocator = control.getRelocator().createDirectRemote( dockable );
	relocator.init( 0, 0, 0, 0 );
	Point defLoc = tDockable.getDefaultLocation();
	relocator.drag( defLoc.x, defLoc.y, false );
	relocator.drop( defLoc.x, defLoc.y );

My subclass has these extra methods

	public void setDefaultLocation( Point defLoc )
	{
		defaultLocation = defLoc;
	}

	public Point getDefaultLocation()
	{
		return defaultLocation;
	}

and the defaultLocation is initialized by

	tDockable.setDefaultLocation( tDockable.intern().getContentPane().getLocationOnScreen() );

The problem is that while the dockable gets moved, it does not end up where it should.

For instance, in my original configuration, I have two tDockables that are stacked. If I move one manually and then use the above code to return it to its original position, it ends up aside the unmoved tDockable.

In another case, when I move a non-stacked tDockable from its original position and then use the above code to return it to its original position, it ends up minimized.

Also, is there some way in common to programmatically move CDockables that I should be using instead?

Thanks for your help and for making such a useful framework available.

Rob

2

CDockable.setLocation? Locations are created with a builder pattern: CLocation.base().normalSouth( 0.5 ).east( 0.5 ).stack( 2 ); And you can ask a CDockable for its current location with “getBaseLocation()”.

3

Sorry, I haven’t explained my problem completely.

Obviously, users get to move their dockables around to create their preferred layout. When they exit the program this layout is saved and restored when they restart the program. This is now the “home” layout and the intent of the “home” action is to take a dockable back to that location.

Originally, I did

	tDockable.setDefaultLocation( ExtendedMode.NORMALIZED, tDockable.getBaseLocation() );

on start up to capture the “home” location, and

	CControl control = tDockable.getControl();
	control.intern().getController().freezeLayout();
		
	tDockable.setVisible( false );
	tDockable.setLocation( tDockable.getDefaultLocation( ExtendedMode.NORMALIZED ) );
	tDockable.setVisible( true );
		
	tDockable.toFront();
	control.intern().getController().meltLayout();

This does not work reliably, I’m guessing because the CLocation is tree specific and the tree has changed to much in many cases to do anything useful.

After reading in the forums about simulating drag and drop, that seemed like a better way to go since the mouse location will always be valid. Which is the code I posted below, which also doesn’t work correctly.

Which of these approaches should I be pursuing and what am I doing wrong in that approach?

Thanks,

Rob

4

You are correct about the issue with a location being a path in a tree - which changes when the user plays around. Are you moving one dockable or many? Because CControl would have the methods “save” and “load” with which you can save and load an entire layout.

Moving just one dockable… honestly I believe there is no solution to this problem. The tree, being a tree, does place some restrictions on which layouts are possible, and which not. You can always create a layout where moving your dockable would result in something that cannot be represented by the tree.