GUICtrlSetOnEvent reagiert in in der zeiten GUI. Warum?

  • Hallo,


    ich bin auf ein dummes Problem gestoßen in der Programmierung mit Autoit. Da mein Ursprünglicher Programmcode den Rahmen sprengen würde, habe ich das Problem vereinfacht zusammengestampft.

    Aufgabe: ich habe ein Gui, in der ich mehrere Aktionen durchführen kann. Anschließend bestätige ich die Einstellungen (Die Einstellungen sind nicht im diesem Code enthalten) und drücke auf OK1. Abhängig von den Einstellungen wird eine zweite Gui erstellt (in diesem Fall lass ich gleich das Programm da rein laufen).

    Da können weiter Optionen ausgewählt werden (die ich hier nicht im Code eingebettet habe).

    Aber das OK2 reagiert nicht auf„GUICtrlSetOnEvent“.

    Was mache ich da falsch?

    Gui2.au3

  • Hey Penner..friendly welcome :D

    Dein Programm hängt im "OnEvent" von $okButton1.
    Ich geh mal davon aus, dass du Gui1, während auf die Eingaben von Gui2 gewartet, nicht ansprechbar machen möchtest.
    Ein kleines Workaround:

    [autoit]

    warten() ;aus den OnEvent-Funktionen entfernen
    GUISetState(@SW_DISABLE, $gui1) ;wenn du nach $gui2 wechselst
    GUISetState(@SW_ENABLE, $gui1) ;wenn du $gui1 wieder ansprechbar machen willst.

    [/autoit]
  • Hallo,

    zunächst ist das Skript im "Opt("GUIOnEventMode", 1)" geschrieben.
    Eine While-Schleife brauche ich schon.
    Ich habe jetzt die Funktion "warten()" ausgebaut.
    Die Befehlen "GUISetState(@SW_DISABLE, $gui1)" & "GUISetState(@SW_ENABLE, $gui1)" helfen da nicht weiter.

    Ziel ist, dass nach dem drücken des "OK2"-Button auch die dahinterstehende Funktion ausgeführt wird.

    Und du darfst mich auch Alex nennen.

  • Dein Problem ist ganz einfach:

    Du hast einen OnEvent-Code. Trotzdem wartet das Programm darauf, das das letzte Event abgeschlossen wurde.

    Leichter verständlich ist es vielleicht so: Dein Programm hat von dir gesagt bekommen, es soll etwas tun, solange "1 gilt" ist. Also durchgehend. Bis du irgendwas anderes sagst. Soweit klar. Jetzt hast du dem Programm aber auch gesagt, wenn ein Nutzer auf den Button hier drückt, mach mal zwischendrin das hier. Bedeutet: Wenn dein Programm mit dem für "zwischendrin" fertig ist, kommt es zu seiner eigentlichen Aufgabe zurück - der Endlosschleife. Wozu solltest du also eine Endlosschleife in der Endlosschleife benötigen? ;)

    Es gibt Tage, da trete ich nicht ins Fettnäpfchen. Ich falle in die Friteuse.

  • "Hey Penner..friendly welcome "
    "Und du darfst mich auch Alex nennen."
    Das war nett gemeint. Ich fand deinen vorherigen Nick lustig.

    BioShade hatt's genauer beantwortet, aber sicherheitshalber: Dein Programm hängt in der Endlosschleife "OkButton"/"zweiteGui"/whatever.
    Meine Idee war dieselbe wie die von BioShade mit den GUISetState(@SW_DIS-/ENABLE)

    Spoiler anzeigen
  • Zitat

    Das war nett gemeint. Ich fand deinen vorherigen Nick lustig.

    Vielleicht nur ein Tippfehler wie einmal bei meinem Benutzernamen? :D
    *ShitDown - Hust Hust*

  • Sorry, wurde zwischenzeitlich für andere Projekte eingesetzt.
    Warum ich in der $gui2 erneut eine Schleife eingebaut habe, liegt an folgenden Tatsachen.
    In der $gui1 erhalte ich Informationen, die ich erst nach der Bestätigung durch "OK1" Auswerten kann. Abhängig von den Informationen, wird entschieden, ob ich in die $gui2 springe. Wenn „ja“, dann kann ich die Informationen aus der Quelle, die in der $gui1 eingegeben wurde, abrufen und auswerten.
    Diese Ausgewerteten Informationen füge ich anschließende als Radio-Button zur Auswahl in der $gui2 ein. Der User muss eine Auswahl treffen und diese mit „OK2“ bestätigen.
    Wichtig für mich ist, dass das Skript solange warten sollte, bis ich die Auswahl in $gui2 getroffen habe und dann mit dem weiteren Maßnahmen fortfahren.
    Toll währe es, wenn die $gui2 sich verhält wie "MsgBox" oder "Inputbox". Dann würde es laufen.
    Ich muss aber eine variable Anzahl an Radio-Button's in dem Fenster bereitstellen.

    Was Bioshade vorgeschlagen hat klingt richtig, kann es aber in meiner Original-Quellcode nicht anwenden.
    Hat jemand eine andere Idee?

  • Wenn du dein Originalskript zeigst kann mir dir viel eher helfen und vorallem nachvollziehen warum die Lösungen nicht funktionieren.

  • Was auch noch gehen würde ist, den OnEventMode in der Funktion wieder zu "abzuschalten". Dann müsstest du in deiner Schleife alle weiteren Abfragen normal durchführen - eben nicht als "onEvent". Wenn du damit fertig bist, müsstest du den OnEvent wieder aktivieren, und alle Events wieder neu setzen.

    Es gibt Tage, da trete ich nicht ins Fettnäpfchen. Ich falle in die Friteuse.

  • Hey. Die Idee hatte ich auch. Traute mich nicht die umzusetzen, weil ich der festen Überzeugung war, das man den Parameter nur einmalig setzen kann.
    Ich werde es mal testen, und gebe dann bescheid. Kann eine Weile dauern. Bin wieder durch ein Projekt blockiert.
    MfG

    • Offizieller Beitrag

    Die ganzen zusätzlichen GUISetOnEvent und GUICtrlSetOnEvent in der Funktion sind gar nicht nötig.
    Und das Sleep in der MsgLoop-Schleife muss raus, weil GUIGetMsg die Ausführungsgeschwindigkeit automatisch regelt und ein zusätzliches Sleep, die Reaktionsfähigkeit der GUI behindert.

    Ich würde das so machen:

  • Oscar : Das Problem ist nur, ohne den Sleep ist von der minimalistischen GUI so manch ein schwächerer PC ein wenig überfordert. Der Sleep blockiert keinerlei Msg. Er reduziert lediglich die CPU-Last.

    Es gibt Tage, da trete ich nicht ins Fettnäpfchen. Ich falle in die Friteuse.

    • Offizieller Beitrag

    Entschuldige, aber das ist Quatsch!
    GUIGetMsg regelt die Prozessorlast automatisch.
    Nur im OnEventMode wird in der Endlosschleife ein Sleep benötigt, weil sonst die Prozessorlast am Anschlag ist.

    Wenn Du mir nicht glaubst, hier ist ein Testprogramm:

    Wenn Du die Maus bewegst bzw. auf der Tastatur tippst, werden mehr Schleifendurchläufe vorgenommen. Bleibt die Maus still stehen und tippst Du nichts auf der Tastatur, dann werden automatisch die Schleifendurchläufe reduziert.
    Ein zusätzliches Sleep kann durchaus zum nicht reagieren der GUI führen, weil während des Sleeps GUIGetMsg nicht ausgeführt wird.

  • Werde es später gerne noch einmal testen.


    Der Test auf der letzten Maschine (alter, wenig leistungsstarker PC) war eindeutig:

    Die CPU-Last war ohne den kurzen Sleep, der keinerlei Msg unterdrückt (zumindest ist mir bisher nicht eine einzige Msg entgangen - in keinem der Programme die ich geschrieben habe und deren Laufzeit im Jahrebereich liegt), deutlich höher - und mit deutlich höher meine ich einen Unterschied von Auslastung zwischen 10 bis 20% und einer Auslastung von 70 bis 80%. Völlig gleich, ob ich den PC verwendet habe, oder das Programm alleine laufen gelassen habe. Natürlich kann es auch mit anderen Faktoren noch zusammenhängen, die die letzte Messung beeinflusst haben könnten.

    Es gibt Tage, da trete ich nicht ins Fettnäpfchen. Ich falle in die Friteuse.