Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4111379

DEFAULT_CURSOR has different semantic on Solaris and Win32

XMLWordPrintable

    • 1.1.8
    • x86, sparc
    • solaris_2.6, windows_nt
    • Verified



        Name: vuC71690 Date: 02/11/98

        uwe@russia

        DEFAULT_CURSOR means parent's cursor on Solaris and default cursor
        (IDC_ARROW) on Win32.

        On Solaris setting DEFAULT_CURSOR results in setting window attributes
        with cursor None, which in X11 means that parent's cursor should be
        used.

        On the other hand, on Win32 when peer is initialized the check is made
        if the target's cursor is default cursor, and if it is then setCursor
        is NOT called on peer. So the cursor handle of the newly created
        window remains null and the parent's cursor is used. But as soon as
        setCursor is called the cursor handle is non null and parent's cursor
        will not be considered. When later DEFAULT_CURSOR is set with
        setCursor, the window cursor is changed to IDC_ARROW cursor, not to
        null (so that parent's cursor is used again).

        So on Win32 component has no way to inherit parent's cursor again once
        setCursor was called on this component.

        There's another problem. As I've already mentioned, on Win32 peer
        doesn't call setCursor when it initializes if the target's cursor is
        DEFAULT_CURSOR. Unfortunately this is implemented incorrectly:

        WComponent.java:

        Cursor c = ((Component)target).getCursor();
                if (c != Cursor.getPredefinedCursor(Cursor.DEFAULT_CURSOR)) {
                    setCursor(c);
                }

        WFrame.java:

        if (!target.getCursor().equals(Cursor.getDefaultCursor())) {
        setCursor(target.getCursor());
        }

        This code relies on the fact, that Cursor.getPredefinedCursor returns
        unique Cursor object from Cursor.predefined array. (Since Cursor
        inherits equals() from Object, the WFrame code effectively compares
        references as well).

        But this assumption is wrong when some Cursor object was deserialized,
        i.e. as part of a component. It has the same type but it's a
        different object, not registered in the Cursor.predefined array. So
        on Win32, when a component is deserialized, even if it has
        DEFAULT_CURSOR type its deserialized Cursor object is not identical to
        the Cursor.predefined[DEFAULT_CURSOR] and so when peer is created
        setCursor is called and the component will never use parent's cursor;
        even though this same component when it was created did use parent's
        cursor. Perhaps Cursor.type should be used to compare cursors.

        ======================================================================

              xdengsunw Xianfa Deng (Inactive)
              duke J. Duke
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: