Docking Frames changes my mouse cursor back to default

Byte-Welt - Projekte / Projects DockingFrames
1

Hello Beni and everybody,

My application changes the mouse cursor when the user starts a certain action (creating a cross-reference). This should happen like this - user selects “Link to node”, cursor changes to DragSource.DefaultLinkDrop, user selects a node to link to, cursor changes back to the default shape. This worked fine until I started using Docking Frames.

Now when the user selects “Link to node” the cursor changes, but then, as soon as the user moves the mouse, it changes back to default. I traced the code and setCursor() is called by SplitDockStation$DividerListener.mouseMoved() and SplitDockStation$DividerListener.mouseExited(), so I am pretty sure it is Docking Frames that is resetting my cursor.

Is there anything I can do about it? I want the cursor to stay the way I set it at least while it is within the JTree where the action occurs.

2

You could disable the call to “setCursor” as described in this thread (you’ll need to scroll down a bit).

Where do you call “setCursor”? Because as I understand the method each Component has its own cursor. And Swing starts searching for the current cursor at the lowest Component under the mouse and then travels upwards. If you call “setCursor” on your JFrame, then it should work as long as your mouse is not over the gap between Dockables?

3

[QUOTE=Beni]You could disable the call to “setCursor” as described in this thread (you’ll need to scroll down a bit).

Where do you call “setCursor”? Because as I understand the method each Component has its own cursor. And Swing starts searching for the current cursor at the lowest Component under the mouse and then travels upwards. If you call “setCursor” on your JFrame, then it should work as long as your mouse is not over the gap between Dockables?[/QUOTE]

I call tree.setCursor() in my menu action handler. tree is a subclass of JTree.

I would expect that if the cursor does not go over the gap between the dockables, it should stay the same, but this is not happening. The cursor switches back to default even though it is nowhere near the divider between the dockables. I think, it might be a bug.

I read the thread you refer to. I am not using the Common framework, only the core. Is there still a way to disable setCursor()? In fact, I don’t want to disable setCursor(). Changing the cursor shape when it is above the dock divider provides very useful feedback to the user.

4

I’ll have to write a small test, it’s a while since I worked on this part of the framework… I’ll write back, maybe not until the weekend.

5

As usual with these kind of errors, I could not reproduce it (which does not mean, that the bug does not exist). I’ve tried an application like the one below. When I change the cursor it stays changed (unless I move the mouse off the tree). Even if I do all kind of drag and drop stuff, the mouse still remains changed over the tree.

What is the difference between your application and my test app?

[Edit: I did use the newest version for this, 1.1.1p5c]


import java.awt.Container;
import java.awt.Cursor;
import java.awt.GridBagConstraints;
import java.awt.GridBagLayout;
import java.awt.Insets;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JScrollPane;
import javax.swing.JTree;

import bibliothek.gui.dock.common.CControl;
import bibliothek.gui.dock.common.CGrid;
import bibliothek.gui.dock.common.DefaultSingleCDockable;

public class CursorTest {
	public static void main( String[] args ){
		JFrame frame = new JFrame();
		CControl control = new CControl(frame);
		frame.add( control.getContentArea());
		
		CGrid grid = new CGrid( control );
		grid.add( 0, 0, 1, 1, createDockable( "A" ) );
		grid.add( 1, 0, 1, 1, createDockable( "B" ));
		control.getContentArea().deploy( grid );
		
		frame.setBounds( 20, 20, 400, 400 );
		frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
		frame.setVisible( true );
	}
	
	private static DefaultSingleCDockable createDockable(String title){
		final JTree tree = new JTree();
		JButton button = new JButton("Cursor");
		button.addActionListener( new ActionListener(){
			@Override
			public void actionPerformed( ActionEvent e ){
				tree.setCursor( Cursor.getPredefinedCursor( Cursor.HAND_CURSOR ) );
			}
		});
		
		DefaultSingleCDockable dockable = new DefaultSingleCDockable( title, title );
		dockable.setLayout( new GridBagLayout() );
		dockable.add( button, new GridBagConstraints( 0, 0, 1, 1, 1.0, 1.0, GridBagConstraints.NORTH, GridBagConstraints.HORIZONTAL, new Insets( 0, 0, 0, 0 ), 0, 0 ) );
		dockable.add( new JScrollPane( tree ), new GridBagConstraints( 0, 1, 1, 1, 1.0, 10.0, GridBagConstraints.CENTER, GridBagConstraints.BOTH, new Insets( 0, 0, 0, 0 ), 0, 0 ) );
		return dockable;
	}
}
6

I’ll make a small POC and post it.

7

I made a small test app, and indeed there is no problem with the cursor. It changes when the mouse is over the separator and changes back when it is not. So, I’ll have to take a closer look at my code and try to figure out what’s happening there. Sorry to have troubled you. If I figure something out, I’ll post it here.

Alla

8

Okay, figured it out. It was my code that messed up the cursor, nothing to do with Docking Frames. Don’t know why debug stack trace had calls from Docking Frames in it. Sorry for the confusion and thanks for your help.

9

Well, good to know you found the bug :wink: