And now things start getting worse and worse! Among other elements the applet has two Swing JSplitPanes and now their contents does not get refreshed any more until I slightly move the separating slider.
In an experimental version I added repaints() all over the place but these seem to have absolutely no effect! Why does Swing not properly repaint updated JPanels?

And what's most annoying: this "Swing update-refusal" is only happening when running as a real applet inside a browser (I tested with IE8 and FF3.5). When running my program as application or testing it in AppletViewer then things are always working perfectly!

What could cause this? Is there some thread in AWT/Swing that can hang or somehow be blocked or what is the reason that applets don't properly refresh???
No wonder the entire world goes Flash and AJAX and what not just to avoid this Applet refresh craze!

Reply viewing options

Overriding paint just to do a println() should be safe as long as you delegate back to super.

I would point out that you probably need to do the same with update() if you want to track all calls to the painting code. paint() is called when there is screen damage from another source (like the window becoming visible on the screen or dragging another window over it), but update() is called in response to calls to repaint() so if you don't override update() then you may miss a lot of Swing's repainting work.

If you read the first article I pointed out then you can get a better idea of how Swing uses both paint() and update() in its paint cycles.

Seems I have to take that on my back! I violated the Swing single thread policy. I had thought, that I had fully obeyed that rule, but had missed a case where via a listener I created Swing calls that did not originate from the AWT event thread and obviously those "bad" calls were the culprit.

Thanks to AspectJ which made it simple to finally pinpoint these errors!

First, I wanted to ask a quick question. Your other thread talks a lot about the paint() method - but Swing applications should avoid that method. If you override it or call it then you will seriously disrupt Swing's painting mechanisms. You should be focusing on paintComponent() instead and leave paint() and update() alone.

(Note that the second article goes over the AWT model first which talks a lot about paint()/update() but if you are writing a Swing application then you want to treat that as "background information" and focus instead on the Swing section of the article which will tell you to use paintComponent(). Unfortunately the article was written a long time ago and fails to stress the need to avoid paint() and update() in Swing applications as much as it should...)

> First, I wanted to ask a quick question. Your other
> thread talks a lot about the paint() method - but
> Swing applications should avoid that method. If you
> override it or call it then you will seriously
> disrupt Swing's painting mechanisms. You should be
> focusing on paintComponent() instead and leave
> paint() and update() alone.

I only had overwritten paint(...) of a few components to add a System.out.println() and then forwarded to super.paint(...). This was just to figure out, if and when paint(...) gets called. Functionality-wise I didn't fiddle with that at all.

> Here are some additional useful resources:

Thanks! I will work through them and see what may be applicable to my problem.

Do you use any api such as JXTransform or other thinks like that which handle the elements displaying and which may responsible of this issue?

I have rencently made some tests with an application I have modified to work as an applet. This one uses some swing components such as JScrollpane, JCombobox, JList, JTable without having noticed any problem.
All the elements appear immediately without needing to click on the applet.
All the refreshing work well too.

The java version I have is also the 1.16.017

Have you a link which could allows to test your applet, maybe the issue is due to a computer configuration issue.

> I had already noticed some artefact issues but that
> was due to the using of Applet class rather than
> JAPPLET.

I *am* indeed using a JApplet. I used "Applet" only as generic term.

> Have you already tried to use java web start rather
> the applet approach?

Alas that's not an option in my case. The app should run in any, unmodified browser (that has a somewhat new Java installed as only req').

> The fact that you have to click on the applet the
> first time to make its content visible is maybe due
> to a security rules matter.
> Have you already tried to use certificate within your
> applet?

The applet IS signed, i.e. it comes with a valid certificate.

> By the way the main element root such as JPanel,
> JSlider , etc. has to be added by the method
> this.getContentPane().add(....)

According to the Javadocs that's redirected automatically (i.e. JApplet overrides add() and forwards .add(...) to .getContentPane().add(...).