methode stoppen / auf ein event warten

[steve]

hallo zusammen,
ich versuche eine methode schreiben, die zwischendurch gestoppt wird. erst wenn ein event auftritt, soll sie weiter ausgeführt werden. ungefähr so:

class Demo implements MouseListener{

	schreibe(1);

	puclic void schreibe(int zahl){
		System.out.println(zahl);
		zahl++;

		//hier soll auf das Event gewartet werden!

		schreibe(zahl);
	}


	public void mousePressed(MouseEvent evt){
		System.out.println("Event!");
	}

}

normalerweise wäre ja alles was nach dem Event passieren soll in der methode "mousePressed". aber dann kann ich leider keine parameter übergeben. ich frage mich, wie man das in so einem fall macht??? :bahnhof:

danke schonmal für alle tipps!

 

[Leroy42]

In event-gesteuerten Umgebungen (GUI, ...) geht das so nicht. Du mußt dir eine
andere Denkweise erarbeiten.

Deine Methoden können(*) nicht warten, sondern sollten immer beendet werden.
Sobald das Ereignis mousePressed eintritt, mußt du eine Methode aufrufen,
die darauf reagiert. In deinem Kurzbeispiel muß zahl also in einer Instanzvariable
gespeichert werden, auf die die bei mousePressed aufgerufene Methode noch Zugriff hat.

(*) Theoretisch geht es schon, indem du einen Thread t aufmachst der erst dann beendet
wird wenn eine bestimmte Flag-Variable gesetzt wird. Diese Variable wird dann bei
Eintreten von mousePressed gesetzt. Und an der Stelle wo du warten willst schreibst du
t.join(), was eben auf Beendigung dieses Threads wartet. Das geht aber nur, wenn
deine schreibe-Methode, in der du warten willst, nicht im Event-Dispatch-Thread
aufgerufen wird; also z.B. selbst eine Methode ist, die durch einen Button-Klick aufgerufen wurde,
da sonst die gesamte Oberfläche eingefroren ist, und keine Events mehr empfangen werden.

Außerdem wäre das eine ziemlich krude Programmstruktur

 

[steve]

sowas hatte ich befürchtet. das problem ist wohl die rekursion. weil die instanzvariable ja immer überschrieben wird. mein programm benutzt aber zwingend diese rekursive methode. ich hab jetzt was gefrickelt, dass es funktioniert. bei jedem rekursionsaufruf wird eine neue instanz einer klasse "Wait" erzeugt, die einen eigenen EventListener implementiert. die instanz der klasse "demo" wird als parameter mit übergeben. wenn ein event eintritt wird von der jeweiligen "Wait"-Instanz die Methode "schreibe(i)" der instanz von "demo" mit dem richtigen wert aufgerufen. klingt gehuddelt, ist es auch. was besseres ist mir leider nicht eingefallen. die rache folgt sogleich: jetzt muss ich rausfinden, woher ich wissen kann, dass die rekursion zuende durchgelaufen ist. mit synchronized kommt man hier jetzt nicht mehr weiter... :?

danke auf jeden fall!

 

[steve]

ich muss nochmal fragen....

auch wenn man eine methode nicht unterbrechen kann, kann man zwischen methoden den code anhalten? oder ist das auch wieder die falsche denkweise? mein konkretes problem sieht so aus:

mein programm berechnet inhalte für einen externen browser. dieser updated die inhalte frameweise. das problem ist nun, (jetzt unabhängig von der rekursion) dass ich methoden habe, die warten müssen bis inhalte die andere methoden vorher erzeugt haben vom browser geupdated wurden. z.b:

- methode1 erstellt ein feld.
- methode2 liest das feld und macht was damit.

in diesem fall muss methode2 bis zum nächsten frame warten. sonst klappts nicht, weil das feld im browser noch nicht exstiert. die info wann der nächste frame berechnet wurde bekomme ich über einem EventListener vom browser. der gibt mir bei jedem frame ein TimeEvent.

mit zeit methoden gehts ja noch, weil ich die zweite in die readableFieldChanged methode reinpacken kann. aber mein ganzes programm, also alle methoden die danach kommen sollen ja auch 'warten'....

wie kann ich jetzt mein programm mit dem browser synchronisieren? das müsste ungefähr so aussehen:

- methode1
warte auf timeEvent
- methode2
warte auf timeEvent
- methode3
- warte auf TimeEvent
- methode4


oder bin ich auf dem holzweg?

 

[Illuvatar]

So etwas geht schon, am besten schaust du dir da mal das java.util.concurrent package an, vor allem die CyclicBarrier Klasse.

 

[steve]

du meine güte.... das problem hab ich irgendwie unterschätzt. :autsch: na, ich werd mich mal reinlesen... danke für den tipp!