-
Bug
-
Resolution: Fixed
-
P4
-
1.1.5, 1.2.0
-
1.1.8
-
x86, sparc
-
solaris_2.6, windows_nt
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2019035 | 1.2.2 | Xianfa Deng | P4 | Resolved | Fixed | 1.2.2 |
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.
======================================================================
- backported by
-
JDK-2019035 DEFAULT_CURSOR has different semantic on Solaris and Win32
-
- Resolved
-
- duplicates
-
JDK-4165128 Component.setCursor() does not allow null
-
- Closed
-
- relates to
-
JDK-4120096 Component spec: behavior of getCursor()/setCursor() not specifed for null cursor
-
- Closed
-