Hallo,
(@ Axel Richter: Du kannst das .jar-file auch entpacken und genauer ansehen. Ich selbst finde (leider) keinen Fehler :-( der mich zur Lösung des Problems führt.)
*g* Ja, toll. Da sind die .class-Files drin. Pack die .java-Files mit ein, dann könnte ich das.
Ups, sorry. Die Klassen sind jetzt im gleichen Ordner wie das jar-file. Du kannst Dir die Klassen also anschauen.
Was passiert?
Life-Cycle eines Applets ist init - start - stop - destroy. Bei init sagst Du:
public void init() {
this.initComponents();
this.setComponents();
this.addText();
this.insert1();
}
Danach ruft insert1 insert2 auf, insert2 ruft entweder sich selbst(ganz schlechter Programmierstil ;-)) oder wieder insert1 auf. Es entsteht also nach insert bereits eine Endlosschleife, noch völlig ohne Threading.
Bei start startest Du, wie bei awt.Applets üblich, den Thread, wobei das Applet selbst runnable ist.
public synchronized void start() {
if (daemon == null) {
daemon = new Thread(this);
daemon.start();
}
}
Das daemon ist als protected Thread daemon definiert.
Darauf hin startet run. Bei run sagst Du:
public void run() {
Thread.currentThread().setPriority(Thread.MIN_PRIORITY);
repaint();
}
Das repaint ruft die update-Methode aller Komponenten des JApplets auf, welche Du nicht weiter definierst. Das bewirkt, einmalig aufgerufen, gar nicht viel.
Je nach Implementation hast Du nun Glück, dass der Thread-Start bei start die vorher bei init gestartete Endlosschleife unterbricht, bei einigen (Opera) eben nicht.
Workaround:
Nimm den Aufruf insert1() aus init komplett raus und starte die Endlosschleife in run:
public void run() {
Thread.currentThread().setPriority(Thread.MIN_PRIORITY);
insert1();
}
viele Grüße
Axel