AWT Automatische Weiterleitung?

Status
Nicht offen für weitere Antworten.

Anyone

Mitglied
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?
 

javimka

Top Contributor
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:
Java:
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

Top Contributor
[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.
Java:
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
 

hdi

Top Contributor
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 :oops:
 

Ebenius

Top Contributor
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 :oops:
Die API-Doc von Runnable sagt was anderes. Siehe hier: http://www.java-forum.org/awt-swing-swt/92656-rausfahren.html#post587311

Ebenius
 

hdi

Top Contributor
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.
 
Zuletzt bearbeitet:

javimka

Top Contributor
hdi, mein Verteidiger :D
Ausserdem passiert im run() von Thread ja auch nicht sooo viel, was man auf keinen Fall überschreiben dürfte ;)
Java:
private Runnable target;
    
public void run() {
    if (target != null) {
        target.run();
    }
}
 

Ebenius

Top Contributor
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

Top Contributor
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

Top Contributor
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 :D
 
Zuletzt bearbeitet:
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
H automatische Anzahl der Spalten ermitteln -> geht nicht AWT, Swing, JavaFX & SWT 6
J Swing Pane im SplitPane automatische Größe aktivieren AWT, Swing, JavaFX & SWT 0
S java.fxml.load.exception und keine automatische Aktualliseriung der Mainausgabe AWT, Swing, JavaFX & SWT 5
I JAVAFX - CSS - automatische Property- und Methoden-Vorlagen in Eclipse AWT, Swing, JavaFX & SWT 17
Neumi5694 Swing Gridbaglayout - automatische Anpassung verhindern AWT, Swing, JavaFX & SWT 1
F Textfeld Währungszahlen und automatische Aktualisierung AWT, Swing, JavaFX & SWT 14
S Swing Warum funktioniert der automatische Zeilenumbruch mit arabischen Zeichen beim JTextPane nicht AWT, Swing, JavaFX & SWT 3
J ungewollt-automatische Größenänderung von JLabel AWT, Swing, JavaFX & SWT 5
S automatische Zeilenhöhen Anpassung bei JTable AWT, Swing, JavaFX & SWT 2
A Automatische anpassung im NullLayout AWT, Swing, JavaFX & SWT 10
N JEditorPane und automatische Scrollposition AWT, Swing, JavaFX & SWT 2
B Automatische Größenanpassung AWT, Swing, JavaFX & SWT 7
K Automatische Skalierung von GUI Elementen (Java Swing) AWT, Swing, JavaFX & SWT 2
N automatische Auswahl einer JComboBox AWT, Swing, JavaFX & SWT 6
C Automatische Screenshots + Analyse des Bildes AWT, Swing, JavaFX & SWT 5
L Layout automatische Anpassung umgehen? AWT, Swing, JavaFX & SWT 5
aze GridLayout: Keine automatische Ausdehnung AWT, Swing, JavaFX & SWT 2
M Automatische Anpassung eines JPanels in einem JFrame AWT, Swing, JavaFX & SWT 6
L JTable automatische Spaltenbreite AWT, Swing, JavaFX & SWT 2
G JPanel automatische Größ AWT, Swing, JavaFX & SWT 4
C JSplitPane automatische Veränderung verbieten. AWT, Swing, JavaFX & SWT 3
T Automatische Grössenanpassung JPanel / JScrollpane AWT, Swing, JavaFX & SWT 3
G GridBagLayout - automatische Größenanpassung AWT, Swing, JavaFX & SWT 3
L jTextField mit automatische Suchfunktion? AWT, Swing, JavaFX & SWT 2
A Automatische Scrollbalken bei einem JFrame AWT, Swing, JavaFX & SWT 8
V event weiterleitung an übergeordnete klasse AWT, Swing, JavaFX & SWT 9

Ähnliche Java Themen


Oben