Repaint Problem on Win 98 when using desktop themes. This problem is seen only when the  mouse pointers are changed using the desktop themes. 

To simulate the problem,
1. Set to one of the desktop themes in Win 98 using the control panel.
2. Run SimpleExample under demos/jfc/Simple in the jdk1.2 directory.
3. Click mouse on the button - This causes the button to be pressed, but the mouse pointer goes below the button. The buton is painted on top of the mouse pointer.
4. Moving the mouse causes the pointer to be painted properly.
5. The same thing happens when the mouse is placed above the button and the button is pressed by the spacebar.





The screen updating beneath the mouse cursor goes wrong. 
This gives an scrambled view at the mouse cursor position.

Move the mouse on a swing button, click it. The screen is refreshed and the mouse 
cursor has dissapeared. When you now move the mouse to
another location, the location where the mouse cursor previously was
was located is now scrambled.
------------------------------
I set my desktop themes off, normal win98 pointers etc., and now it doesn't happen
anymore.
I don't know how this comes, if it is a swing poblem, or a general win98 problem or a
Java problem. I run a jdk1.1. applet in  customer , the molecule example, and there it
also was a problem. So it looks that is not swing related, but Java or Windows
related.

Regards Richard,

(Review ID: 83141)
======================================================================

Turn off the theme which is setting up the fancy cursors.

-----
If -Dsun.java2d.noddraw is used, this bug will disappear. The fix is coming soon.
  xxxxx@xxxxx   1999-05-14

Looks like with Plus! package hardware cursor is replaced by software emulated one. In this case ShieldCursor works not as expected. I am experimenting with 
the possible solution.
  xxxxx@xxxxx   1999-04-22

I have investigated the situation for all scope of platforms (NT, W95,W98). I have fixes for NT and some versions of W95 (depends of drivers though). It will take me two more days to produce one universal fix for all platforms.
  xxxxx@xxxxx   1999-04-29

I've developed many possible fixes, all of them have some impact on performance. We will return back to this bug after figuring out how indid we fix it. It can be "patched" at any time, but I wish to really fix it.
  xxxxx@xxxxx   1999-05-07



  xxxxx@xxxxx   1999-06-07
Regressed on Kestrel 'G'

----------

In response to JDC comments - problems with 1.3.1 on Win2K:
What videoboard is being used?
I can't reproduce the bug on Win2K+Voodoo3 even on 1.2.2 (it's easily
seen on Win98 on the same machine) - it seems to be device-dependent.
(also please note that the workaround is available - either by disabling
use of ddraw or by turning off mouse cursor shadow)

Please check if the bug is reproducuble on 1.4 beta.

  xxxxx@xxxxx   2001-07-26

This should be a top priority bug.
In my case, the all the Swing Demo (JDK1.2) on
Windows 98 is having massive repaint problems as
you move the mouse around. The border painting is
worse.
PLEASE STOP KILLING MY CLIENTS WITH JKD1.2!!!
Subrata Chatterjee (annna111@aol.com)

Because of this bug, shipping products that use Swing is suicide.
I agree with Subrata Chatterjee, this bug should be top priority.
Home users seem to love win98 themes (look how many web sites there are for
them), so the workaround isn't an answer if you want to sell software with a
Swinging gui.
I love Swing, and would love to see/buy/write software that uses it.

I would just like to add that this is not just a problem that occurs in Windows
98. I am still using 95 and had the same problem.
This bug also causes problems with images.

I also have this problem on 2 systems.
one pent 200 mmx with et6000 video chipset & win 95
one pent II 350 with hercules terminator 128 / S3 chipset
and win98.
Both have this problem from jdk 1.2 rc1 and onward.
Swing-applications made with jdk 1.1.6 and swing 1.1 beta3 work fine.
But when running the same application on 1.2 i have the problem of the mouse
garbling
of the gui. Even recompile to 1.2 doesn´t solve the problem.
Switching off mouse trail AND to pure mouse pointer will
solve the problem in 1.2.
I think this can only be a temporary workarround!

SEE also BUG 4160291!!!!!

I have found that on Win98 if I change my screen resolution WHILE my app is
open it then repaints properly.
I love using swing, but this is too big a problem to ignore!!

Please, please, please fix this bug. Our company cannot consider rolling out
our product using Swing until this is fixed on Win98.

It can also be fixed just by changing pointers with the mouse properties in
Control Panel. i.e. You don't have to lose the other features of your theme,
just the pointers

You can also change color depth (hicolor -> true color) while the app is
running to get rid of the repaint problems.
But still this is anoying and looks SO unprofessional!

I have to agree with moverby.  This bug is critical enough to question shipping
a JFC-based application for win98 platforms.

This bug is still present in JDK1.2.1EA

When running Win98 on a laptop, disabling the "trailing mouse" fixes
the problem...regardless of which theme I'm using.

You can also workaround this by going to
MyComputer->Properties->Performance->Graphics and turning hardware
acceleration to None.

I agree with many of the comments above. This bug
simply makes it impossible to seriously develop
a consumer app using the swing API! Please fix
ASAP.

i have this problem on any windows95/98 machine 
which is not set to use the default mouse cursors
(even with the JDK1.2 final release.)
i can deal with this when i am playing around 
with demos etc. but it is impossible to present
programs with this repaint problem.
also, i use extra large cursors with my notebook
and the default cursor is a pain to work with.
i really like swing. please fix this.

I too have seen this problem many times by my clients (in-company personell)
who I have asked to change their pointers.  The only work-around I know of is
to request they use Default Pointers.  I'm about to attempt to change the
pointer when it's over my Swing application in order to "bypass" the
problem entirely.  I'll update if it works.

I am also facing problems with JTable. 
I have added more than 50 rows. 
When I scroll, the painting is not done properly.

Please un-close this bug so I (and about 100 of my friends) can vote for it! It
needs to be fixed! By the way, turning off "show pointer trails"
worked for me. To Sun: when you test your fix, make sure you test it with the
pointer trails option on (I never use Plus! but have had the problem for months
now.)

WORKAROUNDS DON'T WORK.
I am running Win '95 and I have this problem.  I went to
default cursors, that didn't work.  Then I uninstalled Plus!
and that didn't work.  Help!  I have no fancy, trailing
cursors or anything like that.  Default Windows desktop.

Please re-open this bug. It is EXTREMELY important!

I still have this problem with 1.2.2rc1.
The client had set his cursor to the big cursor
under 95 because he operates in 1024+.  Please
fix it.

I disagree with your closing of this bug.  This "dismissal" of this
visual glitching places Swing with the ranks of junior-high-school quality
control.  No one can professionally release a product using Swing with JDK
1.2.x that can be so easily and casually reproduced.  I hope you will
reconsider, re-open and fix this bug!

So are we going to have to wait for release 1.3 for this bug to be fixed?
Can we at _least_ have a good work-around for 1.2.x that allows the Win98
Themes to be used?
I am developing an application using Swing for use where I work. Even though
99% of the software we publish is developed in VB, I was able to write it in
Java. Everyone is impressed by what can be done with Java EXCEPT for those who
use Win98 Themes.
Please fix this bug for 1.2.x! It makes us all look bad!

PLEASEPLEASEPLEASEPLEASE REOPEN this bug ...
It's Getting embarrasing having to reset the screen resolution in front of
clients - and this is only in demo stage - we can't even consider a release
...... you're making VB look like an attractive alternative UUUGGGHHH!

I am running jdk1.2, jdk1.2.1, jdk1.2.2rc over 
Win95 and I have this problem.
Please, fix it.

Sorry, but it's not fixed.

This bug is still not fixed with JDK V1.2.2.
First I've discovered problems with 8 bit colors,
now this. I like Java the language, but Sun's
implementation of Swing is just too buggy.
Visual Basic doesn't have these problems.

Perhaps it's not clear to developers used to a UNIX environment, but this
workaround is simply not feasible in a Windows consumer environment.  You'll
have two kinds of people: those who are furious they can't set their cursors,
and those who set their cursors anyway and refuse to use your app.

Please fix it soon ! It is essential for most Applications ! Don't wait 'til
1.3 !

This bug needs to be fixed ASAP.  It makes developing anything using JDK 1.2
for WIN98 impractical!

Was trying out Swing on JDK1.2.2 to consider moving 
from AWT. Saw the refresh problems. Nice as Swing is,
no way until this bug's fixed.

I having the same problem and it seems to only occur in swing program,
non-swing program are not affected.
Work-arounds:
Run the swing application, make some big changes to the screen, and the app
will now redraw correctly, a good change to make is to put the system in sleep
mode and awake it, but changing screen resolution or color depth caused
Javaworkshop to black out.

Why on earth is this bug closed? PLEASE fix this problem.

FIX THIS BUG! most users of windows 98 have themes
installed, you guys are crazy if you don't fix this.
swing will not be used widely unless this is fixed.

closed? fixed??? I don't understand. as I see this bug was reported dec last
year. jdk1.2.2 hasn't fixed this bug, yet. pleeeease fix it. how can one
develop swing GUI's with this kind of bug. users would go nuts! (you check a
JCheckBox its unchecked after moving the mouse).
funny, that not all computers have this problem, even with 500MHz and 128 MB
RAM, you got problems !!
I need this solved, please! a workaroung or fix would be great!!

Why was this bug closed?  Bueller?  Bueller?
Anybody?

Just downloaded the lastest greatest JDK from this site
and this bug is still there.  I had the 3D mouse 
scheme selected and was seeing this problem.

I thought Java was a great language and a great platform until I encountered
this obnoxious bug.  I tried to fix it by subclassing every graphics class I
could get my hands on but nothing worked.
Now I have to put complex instructions on my freeware product's Web site to
teach novice users how to work around it.  
Apparently, Sun's arrogant geeks (who can all afford LASIK surgery, I suppose)
don't realize that many Windows users use large mouse cursors and large fonts
to compensate for common vision disorders like myopia.  The fact that Sun let a
bug like this slip through makes a mockery of their accessibility support, and
ensures that Java's more interesting features (like Graphics2D) won't be seen
in any consumer products on the Windows platform any time soon.
Sun shouldn't have released JDK 1.2 until they forced whoever was responsible
to fix this code (and then fired them)!!!

Don't worry, it's fixed (at least on my Win98 box) in the JDK 1.3 beta. 
Download it from JDC and see for yourself.

I am in the process of evaluating Java as the basis for an entire
mission-critical enterprise OLTP system. I just downloaded JDK1.2.2 and have
spent the past day an a half trying to get info on this bug. Now I find that it
has been in existance for a long time through several versions of the JDK.
***NOT CONFIDENCE-INSPIRING***

Still a bug in JDK 1.3.0 RC 1.

Easily reproduced on old Micron P90 running win95 and an Acer 312t
running win98.

Simple way to reproduce: Turn on mouse trails. Run the SwingSet2
demo. In the Internal Frames demo, drag a frame under the
always-on-top frame that has the Resisable/closable/... checkboxes.
As you come out from under that frame, you should see cruft in
the window you are dragging and possibly on the background.

Problem goes away with mouse trails off. I don't have desktop
themes installed, so I didn't test those.

I have been not deploying applications on JDK1.2 because of this problem.
I will continue to avoid 1.2 (like the plague it is) as long as this kind of
nonsense exists.  I guess my feeling is that there should be a documented
way to deal with mouse cursors in windows and that the solution should
follow after reading that documentation.  No other application on windows
has this problem except the JVM, so that says something about the path
of solution that sun chose verses what is the documented, acceptable
mechanisms.

jdk1.2  didnt give me this problem on win98.
however, jdk1.2  and jdk1.3rc1  give me this problem.
using stanard cursors and disabling themes does not fix the 
problem.
only disabling graphics acceleration does.
win98 bug? java bug?

Change your screen resolution whilst you are running your 
swing app.  fixes the problem.  change it to a screen res u 
dont use, then back again.   Works a charm.   This may be a 
driver problem...  i'm going to test using a different 
drive for ym stb grpahics card.

Why is this bug closed? It is a critical problem that 
renders Swing unusable for our large-scale OLTP project. I 
really want to use this product, but it is not feasible to 
require our users to change their settings. And, of course, 
I can't distribute an app that uses a beta release of 
Swing. You shouldn't close bugs when the fix isn't 
available in a production release!

This is ridiculous.  It's been how many years since this bug was first reported?  I am trying to develop a GUI 
 with swing, but this bug makes it stupid to do so.  I would enjoy using Java, but until this bug is fixed I will 
simply use VB.

This is absurd.  Any end-user would consider an application garbage if it doesn't display properly, no matter 
how functional, useful, or portable.  Please fix this problem.  Asking an end-user to change system settings 
is a HUGE detractor.

It is the hackman again: sorry I put a dummy email address. 
Here is the real one: stephamk@codeonline.com
I hate hacks !!! Send me the non-hack solution if any.
Regards

JDK 1.3 FINAL VERSION STILL HAS THE BUG.
JDK 1.3 BETA DOES NOT HAVE THE BUG BUT YOU CANNOT INCLUDE 
IT IN YOUR PRODUCTS.
I FOUND OUT A NICE HACK THAT SOLVES THE PROBLEM AS LONG AS 
YOU CAN INTEGRATE IT AT THE RIGHT PLACE. NO NEED TO CHANGE 
ANYTHING IN YOUR SYSTEM SETTINGS:

private void cursorHack()
{  setCursor(new Cursor(Cursor.WAIT_CURSOR));
   setCursor(new Cursor(Cursor.DEFAULT_CURSOR));
}

For example, the bug appears in a JTree when I drag and 
drop nodes. I solve the cursor problem by setting it twice 
to a system cursor at the end of a drop action (I find that 
out when resizing JTree was solving the cursor problem). 
The repaint method sets the cursor back on top of all other 
components.

public void drop(DropTargetDropEvent e) 
{  .....
   cursorHack();
   repaint();
}
		
public void dragGestureRecognized(DragGestureEvent e) 
{  ....
   e.startDrag(...);
   cursorHack();
}

So I don't have any more problems with the layout.
It is up to you to put the hack at the right place into 
your code.

this bug is closed?  disabling fancy cursors is a small 
sacrifice for codeheads and hacker-types... but for 
regular "average jane/joe" computer users?  heck, i can't 
even convince my managers that Java is worthwhile while 
this bug persists.

I am still seeing this in JDK1.3.0 on windows 95.

I just discovered this bug. I am two months away from 
release of this 1/2 million dollar (sold) Java2 program for 
the private industry. I sent it to beta last month and 
discovered this problem on 98.(Not experienced on 95). I 
can't turn back now. Sun, you guys need to come thru with a 
fix. Come on, it's been a year!

Got this bug on a Compaq PII running Win98 with a ATI Rage
Pro video card (4mb). Doesn't happen on a PIII with a Matrox
card. I've reloaded drivers, DirectX, JRE 1.2.2_006 (the
latest), all with the same results. When the cursor moves I
get areas blocked out in the GUI. FIX IT FIX IT FIX IT

That bug still exist in 1.3 and because of it we still have to use 1.1.3 plugin
which doesn't have the problem. Promoting Java with this bug is like trying to 
sell a new fully loaded luxury car with broken windshield and bird shits all 
over it...

With DirectX  8, the "fancy" cursors work (on my computer at least)!

I run JDK1.3, graphics card S3Trio64 V+, Win95B w/Plus!. I've had problems with this bug when using "fancy" 
cursors, so I've had to use the normal ones. Then, a few days ago, I downloaded DirectX 8, and now the 
"fancy" cursors work very well with Swing! Maybe this also works with other graphics cards/other Windows 
versions.

I had the same problem with win2000 & jdk 1.3. 
Found two solutions : a) disabled cursor shadow, b) update 
my Matrox G450 driver to version 5.33
Seems that it also depend on your graphic card.

I have had this same problem running W2k and JDK 1.3 with 
Matrox drivers.  I tried the solution that HerrenM proposes 
and it seems to fix the problem and I can even turn the 
mouse shadowing affect back on without the cursor repaint 
artifacts.  This bug is still troubling.  Users should not 
have to fiddle with video drivers just to get their java 
apps to display properly.

I have a similar problem on JDK1.3 (netscape 6 fix JRE)
on Win 95 (desktop themes on) with a simple Cirrus Logic
5446 2M 2D graphics card on 1024x800 at 24bit. I am using
DirectX7.0, but the same problem occured with earlier
DirectX releases. AWT apps do not have the problem. I
have tried updating the graphic driver, but no improvement
is seen.

However, the -Dsun.java2d.nodraw fix DOES work! It would
be wonderful to know why!

I'm getting the same behavior on the Windows 2000 
Professional platform.  I am not using any sort of cursor 
package.  REALLY unprofessional looking.  So, this is a 
closed and fixed bug?  Hmmm.... I think not.  I'm using 
jdk1.3.1, and it's still happening.  FIX THE BUG!!  REOPEN 
IT!  This makes my big $$ apps look like a 3rd grader drew 
them with a crayon.  Get with it!

I just wanted to pop in and address a couple of the comments on this bug 
I've seen recently:

- The "-Dsun.java2d.noddraw=true" runtime flag 'fixes" the problem
by forcing our renderer to use GDI (as opposed to DirectDraw) when
we copy images onto the screen.  This is essentially what our internal
fix to the problem was: when the cursor is in the way and themes
(and therefore color cursors) are enabled, use GDI for that copy
instead of ddraw.
The reason this works is that there is a conflict between DirectDraw
and software cursors.  Most video cards out there today support
monochrome cursors in hardware and these have no problem running
side-by-side with DirectDraw.  But many video cards (especially 
older or more basic cards) do not support color cursors in hardware,
so they are supported in software.  This support breaks down when
DirectDraw tries to copy bits around in the same space as the cursor.

Anyway, hopefully that explains a little more of what's going on
and how the noddraw flag can workaround the problem

- Windows2000.  Note that this bug was filed against
windows98.  The bug was marked fixed when the problem was
fixed (for a specific jdk release) for Win98 (and win95).  But this
fix does NOT fix a similar problem on Windows2000.  There are
similar issues on Windows2000 and then some. 

In any case, there was a different bug filed against that problem
(4362500).  That bug has also been fixed and you can get
that fix in the latest release of jdk1.4.

Chet Haase.
Java2D team

Have ths same problem with JRE1.3.1 and 1.4.0 on a clients 
machine running Windows 98. Very frustrating to see my 
application crippled with a randomly disappearing cursor and 
very bad for my reputation. I am realizing now that it was a 
big mistake to choose Suns Java over Microsoft tools. 
Releasing a runtime with a bug like this shows how 
unprofessional Suns developers are and closing this bug 
without really fixing it tells about their arrogance.