JDK-4160080 : setCursor fails within JFrame
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.0.2,1.1.7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_nt
  • CPU: generic,x86
  • Submitted: 1998-07-23
  • Updated: 1999-11-23
  • Resolved: 1998-12-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other Other
1.1.8 1.1.8Fixed 1.2.2Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
When a JButton is placed inside a JFrame, calling setCursor in response to an
action event generated by the JButton results in incorrect behavior.  In the
application below, clicking the JButton should cause the cursor to be set to the
Wait Cursor.  Instead, the Wait Cursor appears briefly before being replaced by the Default Cursor.

This bug presents a particular problem for client applications that set the cursor to Wait Cursor while performing an RMI call.  If the cursor is not set properly, the user will often attempt to resubmit the data, clicking the mouse or hitting the return key multiple times, causing the client-side application to hang.  The client must be killed, which interrupts RMI on the server.  When interrupted, RMI may fail to clean up nicely, and it then needs to be restarted on the server before the client-side application can be restarted.

The JDK used is 1.1.6, the Swing version is 1.0.2

------------------------------ TestCursor.java --------------------------------

import java.awt.*;
import java.awt.event.*;
import com.sun.java.swing.*;


public class TestCursor extends JFrame {

    public TestCursor() {

    super("TestCursor");
    setLocation(200,200);
    setSize(200,200);
        addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent e) {
                System.exit(0);
            }
        });

    JButton okButton = new JButton("OK");
    okButton.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent e) {
        setCursor(new Cursor(WAIT_CURSOR));
        }
    });

    getContentPane().add(okButton);
    }

    public static void main(String args[]) {
    TestCursor test = new TestCursor();
    test.show();
    }
}

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.1.8 FIXED IN: 1.1.8 1.2.2 INTEGRATED IN: 1.1.8 1.2.2 VERIFIED IN: 1.1.8
14-06-2004

EVALUATION This is an AWT problem, not a Swing one (Swing knows nothing about cursors). In addition, I've described a workaround which addresses the real problem of a user hitting the application's button twice, instead of the cosmetic solution demanded. thomas.ball@Eng 1998-08-05 I have put back a partial fix for this. It will be totally fixed when setCursor(null) change is put in that makes JButton to inherit its Cursor from its parent. What's going on here is we always have a default cursor (DEFAULT_CURSOR) set for any Component. xianfa.deng@Eng 1998-10-28 With the null cursor changes put in, there is still one problem: the setCursor() on the nativeContainer does not update cursor immediately if the cursor is on a lightweight component. This problem is fixed in Container.setCursor(). xianfa.deng@Eng 1998-12-15 ----------------------------------------------------------------------- This bug was verified as fixed via regression testing using jdk118L. tao.zhang@eng 1999-03-29
15-12-1998

WORK AROUND If an application doesn't want a button to be pushed twice, the correct approach is to disable the button after the first click. The busy cursor is just an indication to the user that the system is in use, and in no way enforces the behavior your app requires. thomas.ball@Eng 1998-08-05
05-08-1998