AWT Automatische Weiterleitung?

[Anyone]

Guten Abend,

ich suche nach einer Möglichkeit mit AWT automatische Weiterleitungen von einem Frame zu einem anderen Frame nach einem bestimmten Zeitraum (beispiel 3 Sekunden) zu realisieren. Geht sowas und wenn ja wie?

 

[eRaaaa]

klar , sollte eig. mit nem timer (vllt swing timer? -> How to Use Swing Timers (The Java™ Tutorials > Creating a GUI With JFC/Swing > Using Other Swing Features)) möglich sein. nach ablauf, einfach aktuellen frame ausblenden, neuen einblenden ?!

/edit: ups, das AWT hab ich glatt überlesen, sry ;(

 

[Anyone]

klar , sollte eig. mit nem timer (vllt swing timer? -> How to Use Swing Timers (The Java™ Tutorials > Creating a GUI With JFC/Swing > Using Other Swing Features)) möglich sein. nach ablauf, einfach aktuellen frame ausblenden, neuen einblenden ?!

Ich suche allerdings nach einer AWT-Möglichkeit.

 

[javimka]

Du könntest dem Frame einen ComponentListener anfügen und [c]public void componentShown(ComponentEvent e)[/c] überschreiben. Wenn das Frame dann angezeigt wird, wird componentShown ausgeführt. In der Methode würdest du folgendes schreiben:

new Thread() {
	public void run() {
		try {
			Thread.sleep(3000); // warte 3 Sekunden
			otherFrame.toFront();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}.start();

Diese Methode setzt das andere Fenster in den Ordergrund, oder was auch immer nötig ist.

Wenn nicht ComponentListener, könnte vielleicht ein FocusListener noch helfen. Schau es dir mal an

 

[Ebenius]

[java=2]public void run() {[/code]

Niemals nicht die [c]run[/c]-Methode eines Threads überschreiben. Besser ein Runnable implementieren und dem Thread zur Ausführung übergeben. Davon abgesehen finde ich einen java.util.Timer schöner als einen Thread. Ansonsten sollte man auch in AWT synchron zum EDT bleiben.

final java.util.Timer timer = new java.util.Timer(true);
timer.schedule(new TimerTask() {
  
  @Override
  public void run() {
    EventQueue.invokeLater(new Runnable() {
      
      public void run() {
        otherFrame.toFront();
      }
    });
  }
}, 3000);

Ebenius

 

[javimka]

EDIT: Alles klar

 

[hdi]

Niemals nicht die run -Methode eines Threads überschreiben. Besser ein Runnable implementieren und dem Thread zur Ausführung übergeben.

Hä... Ob man ein Runnable in einen Thread verpackt oder direkt einen Thread startet ist doch das selbe. Runnable gibt's doch nur weil es keine Mehrfachvererbung gibt. Und run() wurde doch auch in javimka's Post überschrieben - Das @override ist doch nur ne Annotation?! Oder wie, oder was? Klär mich mal auf ich versteh das net so ganz

 

[Ebenius]

Hä... Ob man ein Runnable in einen Thread verpackt oder direkt einen Thread startet ist doch das selbe. Runnable gibt's doch nur weil es keine Mehrfachvererbung gibt. Und run() wurde doch auch in javimka's Post überschrieben - Das @override ist doch nur ne Annotation?! Oder wie, oder was? Klär mich mal auf ich versteh das net so ganz

Die API-Doc von Runnable sagt was anderes. Siehe hier: http://www.java-forum.org/awt-swing-swt/92656-rausfahren.html#post587311

Ebenius

 

[hdi]

Das ist doch einfach nur ein allgemeiner Programmiertipp in OO-Sprachen, den Sun da in die API gezogen hat. Interfaces sind immer besser als Subclassing. Ich meine gibt es dafür eine Begründung basierend auf auf der JLS, warum es wirklich schlecht ist von Thread zu erben auch wenn man nur run() überschreibt? Nein, denn wenn es konkrete Auswirkungen an manchen Stellen in der Implementierung hätte, würde es dort konkret stehen. zB die Klasse so und so nutzt die Methoden so und so von Thread, und deshalb kann's Probleme geben wenn man da run() überschreibt und bla...
Ich sag nicht dass das, was dort steht, irgendwie falsch ist, aber es ist nur ein Tipp, sowas wie "It is important to use the Point API class instead of writing your own class for that, because it would be unnecessarry to do that"...
Naja kA. Also dein Ausruf kam für mich etwas alamierend rüber, als wär's jetzt todesschlimm run() zu überschreiben In Wahrheit ist es das selbe, der Grund warum es Runnable gibt ist wirklich die Kompensation der fehlenden Mehrfachvererbung. Ich meine schau dir das Interface doch mal an. eine einzige Methode, und soweit ich weiß auch nur von der Thread-Klasse genutzt, oder vllt noch SwingWorker etc. Also wirklich einfach nur alles, was man starten kann, genau so wie Threads.

 

[javimka]

hdi, mein Verteidiger
Ausserdem passiert im run() von Thread ja auch nicht sooo viel, was man auf keinen Fall überschreiben dürfte

private Runnable target;
    
public void run() {
    if (target != null) {
        target.run();
    }
}

 

[hdi]

@javimka: YES, Ebenius geowned. High Five!!

 

[Ebenius]

Muahaha... Man erzeugt eine Ableitung dann, wenn man eine Klasse funktional erweitert. Der Thread wird nicht funktional erweitert sonden nur genutzt. Aus diesem Grund keine Erweiterung. Natürlich ist die Welt voll von schlechten Lösungen die auch funktionieren; das ist unstrittig. ;-)

Ebenius

 

[javimka]

Würde ich eine neue Klasse schreiben, die von Thread erbt, würde ich wohl nicht einfach die run() Methode überschreiben, weil andere Programmierer, die eine Instanz meiner Klasse erstellen davon irritiert werden könnten. Hier verwende ich die Klasse allerdings annonym und instanziere kein Objekt davon. Da finde ich, dass es in Ordnung geht, denn der einzige Unterschied zur Verwendung eines Runnables wäre, dass noch mehr Code geschrieben würde und dass das run() von Thread einfach das run() vom target aufruft.

 

[hdi]

Man erzeugt eine Ableitung dann, wenn man eine Klasse funktional erweitert.

Eigentlich noch nicht mal dann. "Echtes" Ableiten, also extends, sollte man an sich nur nutzen wenn man die Eigenschaften braucht (Instanzvariablen), nicht die Funktionalität nach außen. Solange man nur gewisse Methoden haben will sollte man immer nur zu einer Komposition hindelegieren. Aber schon klar, wer macht sich schon für jede kleine asslige Klasse erstmal ein Interface, dann eine Default-Implementierung, und dann letztendlich eine Klasse, die das Interface als Komposition nutzt und zur Laufzeit durch die Default-Implementierung instantiiert (Ja, das ist genauso umständlich und verwirrend wie es sich anhört). Zumindest hab ich das schon öfters gelesen, dass Vererbung von Programmierern zu oft verwendet wird und eig. nur in paar % der Fälle wirklich genutzt werden sollte. Eben nur dann, wenn man wirklich eine echte Ableitung mit allen Attributen rechtfertigen muss. Das ist sinnvoll bei den Anfänger-Beispielen vonwegen Fahrzeug, PKW, LKW, Motorrad usw. Aber in der Praxis hat man diese eindeutige "ist"-Beziehung bei den Klassen eines Programms meist nicht, da die Klassen nicht wirklich so klare Objekte aus der realen Welt sind. Und dann sollte man halt auch nicht ableiten. Denn wenn das Auto in meinem Race-Game nicht so stark zur Laufzeit gebunden ist, dann kann ich in später mal die 4 Reifen austauschen durch 2 Kühlschränke und eine tote Ratte... Naja wer's braucht