Ich habe hier zwei Klassen gegeben. Eine Klasse Applikation, welche zwei Methoden besitzt. Die erste ist run(), welche ein int zurueckgeben soll. Die zweite ist exit, welche die Applikation beendet. Als Parameter nimmt es ein int an, dass als exit code dient.
Diese Klasse wird von einer Klasse Handler gestartet. Je nachdem wie Applikation beendet wird(also was run() zurueckgibz), muss der Handler ein paar Sachen abarbeiten.
Ich wurde beim Googlen und auch schon hier auf [japi]Future#get()[/japi] verwiesen, jedoch denke ich mal, dass das Problem eher in der Klasse Applikation, genauer in der run() Methode liegt. Sie muss eben so lange laufen, bis exit gerufen wird und gibt dann den uebergebenen code zurueck.
[quote=groggy]Ich habe hier zwei Klassen gegeben.[/quote]Wäre hifreich wenn Du eine KSKB Posten würdest
[HR][/HR][quote=groggy;78424]Die zweite ist exit, welche die Applikation beendet. Als Parameter nimmt es ein int an, dass als exit code dient./quoteStatus als Rückgabewert einer Methode zu nutzen ist in der OOP verpöhnt.
[quote=groggy;78424]Diese Klasse wird von einer Klasse Handler gestartet. Je nachdem wie Applikation beendet wird(also was run() zurueckgibz), muss der Handler ein paar Sachen abarbeiten.[/quote]Warum muss der Händler dann die run-Methode der Klasse Applikation in einem Thread starten? Es wäre dann doch sinnvoller, wenn die ganze Methode des Handlers im selben Thread wie Applikation.run() laufen und den Rückgabewert dann auch direkt bekommen würde.
@CyborgBeta danke hat diesmal aber nichts mit Bits zu tun ^^
@TT Die Klasse Applikation wird auch im gleichen Thread gestartet. Nur die Methode heisst eben run.
public class Application {
public int run() () {
// Solange in der Methode bleiben, bis exit gerufen wird.
return exitCode;
}
public void exit(int exitCode) {}
}```
So sieht es kurz und knapp aus. Der Handler soll dann je nach exit code bestimmte Sachen erledigen. Wie ich oben schon meinte, liegt das Problem eher in der run Methode. Was mit aber eben noch eingefallen ist: Man kann einfach einen Listener erstellen und der wird aufgerufen wenn die Application sich beendet. Scheint bis jetzt die sauberste Sache zu sein die ich kenne(da du ja eben meintest sowas wuerde nicht in die OOP Welt passen ;))
du willst das eine methode so lange (also vermutlich ein loop) ausgeführt wird bis eine andere methode gecallt wird … hab ich das so weit verstanden ?
wie wäre es dann einfach mit einem flag ?
public void run()
{
while(flag)
{
}
}
public void exit()
{
flag=false;
}```
oder wird der rückgabe-wert (wie gesagt : sowas macht man nicht) in exit gebraucht ?
dann kann man es auch ein wenig "gewaltsamer" machen
```int superglobal=0;
//...
Thread t=new Thread(new Runnable()
{
public void run()
{
//...
superglobal=1;
}
});
//...
t.start();
//...
public void exit()
{
t.interrupt();
}```
einfach von "außen" den thread mit interrupt abbrechen ... ist aber noch unsauberer
vielleicht verrätst du uns erstmal genau was ablaufen soll
du redest irgendwas von nem handler der abhängig vom ergebnis irgendwelcher operationen dann noch weitere durchführen soll ... ABER erst wenn man VON WO AUCH IMMER die exit() methode callt
vllt hilft es zu klären wer oder was von wo aus exit() callt und warum du einen return-wert dieser übergeben willst anstatt dies einfach ein einem privat-field im objekt zu speichern
irgendwie klingt das nach nem völlig falschen ansatz um irgendwas vermutlich recht einfaches zu lösen
aber so wie du versuchst ranzugehen stellst du dir nur irgendwie selbst ein bein
[QUOTE=groggy]@TT Die Klasse Applikation wird auch im gleichen Thread gestartet. Nur die Methode heisst eben run.
public class Application {
public int run() () {
// Solange in der Methode bleiben, bis exit gerufen wird.
return exitCode;
}
public void exit(int exitCode) {}
}```[/QUOTE]
Sofern in run() nicht exit() aufgerufen wird, sind auf jeden Fall zwei Threads im Spiel (oder das Programm beendet sich nie...). Mit dem kleinen Fragment, welches du gepostet hast, kann man noch nicht so viel anfangen.
Es geht um ne Klasse Application (vorgebenen). Sie stellt ne GUI da. Beim Schliessen des Fensters wird nun die Methode exit mit dem wert 0 aufgerufen. Drueckt der User aber auf neustart, so wird der wert 1 uebergeben. Nun soll der Handler bei 1 einfach nochmal run aufrufen und fertig.
Unsere Aufgabe(bze meine): Implentiere einen Weg, die Applikation neu zu starten…
ist dann nun deine Frage wie du eine Methode aufrufst, wenn die GUI geschlossen wird (zb WindowListener)
oder wie du die Applikation dann neustarten kannst ? (hmm… einfach die richtige Methode aufrufen ?)
Meine Frage war es eig, wie ich solange in der Methode run bin bis die Methode exit aufgerufen wurde. Habe das jetzt eimfach mit dem Listener gemacht, der angestupst wird, wenn man exit aufruft.
Spaeter soll es (als Extraaufgabe) moeglich sein, Automatische Updates des Programmes aus dem Internet zu beziehen. Ich haette es ja alles persoenlich nach RCP oder e4 portiert und fertig xD aber ne, ihr duerft keibe libs verwenden…
@mymaksimus
Ich weis nicht warum, habe aber bei dem Kommentar einen Lachflash bekommen ^^
Btw: hab mit dem geredet, mittlerweile hat er mir ne 2- gegeben xDD
drücken wir das ganze mal etwas zusammen, so kommen wir auf 2 klassen : den launcher/handler/wie auch immer … und die eigentliche anwendung / application / etc
was verlangt wird : controller soll auf “ende” der app warten und abhängig von ihrem exit-code entweder die VM komplett beenden oder die app “neu starten”
ich hoffe soweit erstmal korrekt … oder ?
dann ist die lösung recht banal (wenn auch recht unsauber weil man sowas eigentlich nicht macht)
launcher->main : baut den launcher soweit zusammen das dieser selbstständig (also in einem weiteren, unabhängigen thread) weiterläuft
launcher->launch : call main() der app
app->main : baut die app soweit zusammen, enthält am ende einen call setVisible(true) z.b. auf ein JFrame
das JFrame bekommt als default DO_NOTHING_ON_CLOSE und einen WindowListener/Adapter der beim “beenden” die frage stellt : exit or reboot ?
im launcher läuft ein loop der prüft isVisible() und bei false mit hilfe eines globalen flag was durch die app im launcher gesetzt wird entweder erneut main() anstößt oder sich selbst terminiert
klar kann man den listener auch im launcher implementieren und dann an der eigentlichen app registrieren (ist vllt noch etwas sauberer), aber : WOZU ?
wenn ich eine anwendung BEENDEN will, dann werde ich auf die frage : “Anwedung neu starten” mit sicherheit NEIN antworten
und wenn ich die app manuell neu starten will, z.b. auf grund von fehleren oder eines “absturzes” würde ich das nicht der app selbst überlassen
zu mal in den meisten fällen wo man sowas brauchen könnte sich die ganze VM mit abschießt oder aus anderen gründen nicht mehr reagiert oder nicht beendet werden darf (z.b. ungesicherte daten)
allgemein also recht einfach zu lösen, aber kein wirklich sinnvolles anwendungsgebiet
(und wer jetzt mit self-updates kommt : das würde ich noch anders lösen)
Das mit den self updates würde mich noch interessieren (ich hätte RCP o.ä. genommen)…
Es gibt nen Menüpunkt Neu Starten. Es wird nicht immer nach neu starten gefragt
[QUOTE=groggy]@mymaksimus
Ich weis nicht warum, habe aber bei dem Kommentar einen Lachflash bekommen ^^
Btw: hab mit dem geredet, mittlerweile hat er mir ne 2- gegeben xDD[/QUOTE]
[ot]
Gerade bei Github gefunden. How to make your own OS
mega interessant und irgendwie habe ich jetzt Bock auf sowas xD [/ot] btw: existiert der OT Tag ueberhaupt?
hat diesmal aber nichts mit Bits zu tun ^^