-
Bug
-
Resolution: Cannot Reproduce
-
P4
-
None
-
1.1.4
-
sparc
-
solaris_2.5.1
See background in bug 4065596.
Here is a comment from that bug report that describes the solution:
The immediate cause of this bug is found in awt_MToolkit.c
We had been using XtAppSetFallbackResources() to establish certain
fallback resources. This works only as long as there is no X app-
defaults file present in any form. But if an app defaults file is
found, then this will not set fallback resources. Well, between
master builds 114 and 165, this function call became ineffective,
implying that an app-defaults file can be found in the later build.
The fix in awt_MToolkit.c implements a more robust way to establish
fallback resources, even in the presence of an X app-defaults file.
We use X primitives to construct a resource database of fallbacks,
and then combine this (non-destructively) with the main (display)
resource database. This, our fallbacks are guaranteed established.
erik.larsen@Eng 1998-07-09
I've been unable to reproduce this one.
Here is a comment from that bug report that describes the solution:
The immediate cause of this bug is found in awt_MToolkit.c
We had been using XtAppSetFallbackResources() to establish certain
fallback resources. This works only as long as there is no X app-
defaults file present in any form. But if an app defaults file is
found, then this will not set fallback resources. Well, between
master builds 114 and 165, this function call became ineffective,
implying that an app-defaults file can be found in the later build.
The fix in awt_MToolkit.c implements a more robust way to establish
fallback resources, even in the presence of an X app-defaults file.
We use X primitives to construct a resource database of fallbacks,
and then combine this (non-destructively) with the main (display)
resource database. This, our fallbacks are guaranteed established.
erik.larsen@Eng 1998-07-09
I've been unable to reproduce this one.