Wie kann man etwas in der MainLoop ausführen?

    • Offizieller Beitrag

    Wenn ich in AutoIt den OnEventMode verwende, dann gibt es ja auch eine "MainLoop":

    Wenn ich das Gleiche aber in Nim machen will, dann klappt das nicht (Absturz):

    Was passiert denn da noch in "app.mainLoop"?

    • Offizieller Beitrag

    Da hatte ich auch schon mal gesucht.

    mainLoop() (wApp.nim #212) verwaltet nur die eigentliche Schleife: messageLoop() (wApp.nim #181).

    Aber wie man dort eigenes Handling einbringen kann....:?:

    Ich vermute, dass man alles über eigene Events regeln muss, die dann mit frame.wEvent_Irgendwas ausgeführt werden.

    • Offizieller Beitrag

    Ich vermute, dass man alles über eigene Events regeln muss, die dann mit frame.wEvent_Irgendwas ausgeführt werden.

    Das geht aber nicht immer.

    Eine Event-Prozedur sollte so schnell wie möglich wieder verlassen werden (genau wie in AutoIt), weil sonst die GUI nicht aktualisiert wird bzw. andere Events warten müssen.

    Ich möchte bei einem bestimmten Event (Buttonclick) eine Auswertung machen. Dort werden auch Sounds ausgegeben. Außerdem will ich einige Buttons sperren (disable). Das passiert aber erst, wenn die Event-Prozedur wieder verlassen wurde.

    Um das zu umgehen, wollte ich nur einen Marker setzen (bStart im obigen Beispiel) und die eigentliche Auswertung dann in der Mainloop erledigen. Damit würden die Buttons schonmal gesperrt und die Sound würden erst in der Mainloop abgespielt werden.

    Aber wenn das nicht klappt, muss ich wohl eine Timer-Prozedur verwenden:

    • Offizieller Beitrag

    muss ich wohl eine Timer-Prozedur verwenden:

    Mist! Das klappt auch nicht. Wenn ich mal ein Sleep(1000) als Test verwende, dann hakelt das Ganze (Versuch, das Fenster zu bewegen, zeigt das).

    Auch ein "frame.stopTimer" hilft dabei nicht: X/

    • Offizieller Beitrag

    Ok, ich habe doch noch eine Möglichkeit gefunden: MultiThreading

    Ich erstelle meine eigene Mainloop und lasse diese in einem zusätzlichen Thread laufen:

    Achtung! Beim compilieren muss --threads:on angegeben werden!

    • Offizieller Beitrag

    Ich denke mal, das sollte auch mit asyncdispatch zu lösen sein. Leider sind die Beispiele nicht sehr hilfreich, basieren alle auf client-server Geschichten.

    Ich habe das so verstanden.

    - Mann benötigt ein Future-Objekt, das den Wert enthält der erreicht werden soll um die Async-Proc zu starten. Ich habe kein Bsp. gefunden, wie man newFutureVar den Zielwert zuweisen kann.

    - In der Async-Proc warte ich dann darauf, dass Future erreicht wird (so etwa: await future). "await" pausiert nur die Async-Proc.

    - die Async-Proc wird gestartet mit asyncCheck procXY()

    Aber ich habe hin-und herprobiert. Die Arbeit mit Future geht immer irgendwo daneben, Typ passt nicht oder Instanzierung der Prozedur nicht möglich. X(

    • Offizieller Beitrag

    Das mit dem zusätzlichen Thread sieht bisher sehr gut aus. Ich denke, dass ich erstmal damit weiter mache.

    Ich habe noch einen "Trick" gefunden, wie man den "--Threads:on" Parameter auch beim Start von VSCodium ausführen lassen kann:

    Man muss im gleichen Verzeichnis wo die "nim"-Datei liegt, eine Datei mit dem gleichen Namen aber der Endung ".nims" (s am Ende) erstellen und dort folgendes eintragen: --threads:on.

    Das war's schon. Beim Start von VSCodium werden dann auch Threads benutzt.

    • Offizieller Beitrag

    Es war ja klar, dass das nicht so einfach sein kann. X/

    Wenn ich jetzt meine "ooSound" benutzen möchte, um die Sounds abzuspielen (im zusätzlichen Thread), dann stürzt das Programm ab, sobald ich auf den Button klicke und es kommen folgende Meldungen:

    Damit ihr das nachvollziehen könnt, habe ich mal alle benötigten Dateien zusammengepackt (Anhang).

    Nach meinen Recherchen im INet, kommt das wohl vom Garbage Collector (GC), weil ich ja ein Sound-Object vom Mainthread verwende.

    Aber wie kann ich das Problem lösen?

    • Offizieller Beitrag

    So, nach ewigem Probieren und Suchen habe ich es (hoffentlich) hinbekommen. Teste mal, ob das wie von dir gewünscht funktioniert.

    EDIT:

    Hmm, das scheint so auch nicht zu gehen, wenn ich in die Async-Proc eine Schleife hänge, wartet Button_event bis die Schleife beendet ist - also nicht async.

    • Offizieller Beitrag

    Teste mal, ob das wie von dir gewünscht funktioniert.

    Nee, das funktioniert nicht. Eine Schleife in der Proc blockiert alles.

    Mit der Thread-Geschichte bin ich jetzt etwas weiter. Wenn ich das Sound-Object (was ich im Thread verwende) nochmal im zusätzlichen Thread generiere, dann klappt das ohne Absturz. Finde ich zwar nicht optimal, aber was soll's? Speicher gibt's ja genug. ;)

    Das hat also wohl damit zu tun, dass mein ooSound nicht Threadsicher ist. Aber da ich zum ersten Mal mit Multithreading zu tun habe, weiß ich überhaupt nicht, wo ich da ansetzen soll, um das zu ändern (falls das überhaupt geht).