Warten bis das Form neu gezeichnet wurde?
Dies ist ein Thread, auf den aus der FAQ verwiesen wird. Bitte keine weitere Diskussion, sondern nur wichtige Ergänzungen und diese bitte knapp und präzise. Vielen Dank!
Mahlzeit!
Ich hab hier ein Form das leider nicht mehr richtig dargestellt wird sobald mal ein anderes Fenster drübergeschoben wird o.ä. da nebenher ziemlich viel gerechnet werden muss, deshalb wollt ich fragen ob es da eine möglichkeit gibt zwischendrin immer zu warten bis die Form neu gezeichnet wurde?
mfg Muphin
Hallo Muphin,
zu warten, bis die Form neu gezeichnet wurde, ist der falsche Ansatz. Du solltest die Berechnung in einen extra Thread auslagern, so dass sich das GUI immer neu zeichnen kann.
Such' mal hier im Forum nach Begin bzw. Endinvoke. Das Problem wurde schon häufig angesprochen und gelöst.
Gruß,
Fabian
"Eine wirklich gute Idee erkennt man daran, dass ihre Verwirklichung von vornherein ausgeschlossen erscheint." (Albert Einstein)
Gefangen im magischen Viereck zwischen studieren, schreiben, lehren und Ideen umsetzen…
Blog: www.fabiandeitelhoff.de
An sowas hat ich auch schon gedacht, aber da das grad eher was kurzes zum ausprobieren werden sollte wollt ich mich da nich gleich in Multithreading einarbeiten!
Aber dankeschön, ich werd mal suchen!
Der BackgroundWorker nimmt dir unter umständen einiges an Arbeit ab
In den verlinkten Threads wird es bestimmt auch gesagt.
Aber damit man nicht so viel suchen muss poste ich es hier nochmal.
Mit Application.DoEvents() kann man alle Arbeiten die gerade anstehen ausführen lassen (grob gesagt). Auch die Arbeit, das Fenster neu zeichnen zu lassen.
Damit müsste es also gehen.
Leider scheinen nur wenige diesen Befehl überhaupt zu kennen. Dann werden Mulitthreads eingebaut wo gar keine hinmüssen und auch keine hingehören.
Yunky: was fürn operator muss ich den nehmen wenn ich sagen will nichtgrößergleich??
Yunky: !>3??
Yunky: !≥ ??
Puppetmaster: G
Yunky: aja ka
Puppetmaster: kleiner (<)
Yunky: stimmt^^
Es ist eher andersrum das DoEvents nur eine Krücke ist.
Es ist ein Überbleibsel aus der Zeit, als die Programmierung von Threads
zu schwer war.
Heutzutage mit System.Threading.Thread oder dem Backgroundworker ist es
dumm die dann zu erreichende Performance und Einfachheit nicht zu benutzen.
Wie oder wo willst Du z.B. ein DoEvent machen bei einem DataAdapter.Update()
das länger läuft?
Hallo Puppetmaster,
oh, da hatte ich die Frage falsch verstande. Durch deine Antwort ist es mir aber klar geworden, was mit der Frage gemeint war. Allerdings sehe ich es so wie FZelle, das ist kein Fall für DoEvents, sondern für Threads.
Hallo zusammen,
Alles weitere in der FAQ: [FAQ] Warum blockiert mein GUI?
herbivore
Ist doch schön wenn sich ein Problem einfach lösen lässt. Warum es sich schwer machen wenns auch einfach geht.
Prinzipiell sind Threads natürlich der richtige Weg.
Aber wenn ich mir jetzt eine kleine Klasse (z.B. eine eigene Form mit ner ProgressBar drauf) schreibe, finde ich es ganz sinnvoll nachdem die ProgBar durch eine Methode geändert wurde diese mit einem DoEvent zu "aktualisieren".
Dafür jetzt einen eigenen Thread zu starten fände ich übertrieben.
Natürlich muss man mit diesem Befehl vorsichtig sein und darf ihn nicht als Allheilmittel (wenn man denn eins sucht) für Threads sehen.
Aber ich finde er hat dennoch seine Daseinsberechtigung.
Yunky: was fürn operator muss ich den nehmen wenn ich sagen will nichtgrößergleich??
Yunky: !>3??
Yunky: !≥ ??
Puppetmaster: G
Yunky: aja ka
Puppetmaster: kleiner (<)
Yunky: stimmt^^
Naja, hier n bischen gepfusche da n bischen gepfusche und schwups hat man das große chaos
Natürlich funktioniert die Methode. Und vielleicht hat sie auch eine Daseinsberechtigung. Allerdings stellt es halt einfach keine saubere Programmierung dar, wenn die langlaufende Aktion dem Benutzer vorschreibt, wann er irgendeine Aktion mit dem Fenster machen darf.
Man kann immer irgendeine Möglichkeit für DoEvents konstruieren.
Dennoch ist das mit Threads sauberer. Einer für das Fenster und alle dazugehörigen Ereignisse sowie Interaktion mit dem Nutzer und einer nur zum Rechnen.
Und ich finde es ehrlich gesagt einfacher, einmal die Zeile
myBGThread = new Thread( new ThreadStart( myThreadProc ) ); zu schreiben, als immer nachzudenken, wann und wo ein Application.DoEvents() angebracht ist...
Erst mal ein Dankeschön an euch, da ihr mir wieder gut geholfen habt!
Ich bin auch ehrlich gesagt froh das Puppetmaster mir den Tipp mit Application.DoEvents() gegeben hat, denn so war die Sache mit einer Zeile Code für mich erledigt!
Klar is das so keine saubere Sache, aber für diesen Fall dass ich kurz was gebraucht habe um mir die Sache immer neu zeichnen zu lassen was im späteren Programm wahrscheinlich nicht mehr nötig ist eine echt gute Sache!
Man sollte es eben nur nicht immer einfach so verwenden weils bequemer ist!
MFG Muphin
Original von Puppetmaster
Ist doch schön wenn sich ein Problem einfach lösen lässt. Warum es sich schwer machen wenns auch einfach geht.
Weil es keine Lösung ist. DoEvents() macht Probleme beim Schliessen der Anwendung.
Angenommen du befindest dich in einer Methode des Fensters und drückst den Schliessen-Button. DoEvents() sorgt dafür, dass das Fenster mitten in der Methode abgebaut wird. Dann wird der nach DoEvents() folgende Code weiter ausgeführt. Greifst du jetzt hier auf ein Control des Fensters zu macht es BUMM.
Grundsätzlich sollte man daher DoEvents() nur dann aufrufen, wenn die Message-Pumpe nicht läuft - also eigentlich nie....
Oder man stellt sicher, dass das Fenster nicht schlíeßt.
Keeping your UI Responsive and the Dangers of Application.DoEvents
wow. Hätte nicht gedacht, dass des so ne Diskussion gibt. Find ich aber immer wieder schön, wenn es Streitthemen gibt.
Bzw. momentan sieht es wohl eher so aus, dass ich gegen den Rest der Welt stehe. Obwohl normalerweise immer ich derjenige bin der "sauberen" Programmierstil predigt ^^.
Also, DoEvents() ist gefährlich. Da sind wir uns wohl alle einig.
Bloß, dass es prinzipiell falsch ist will ich jetzt nicht behaupten.
Ich denke, wenn man das ganze mit Vorsicht genießt müsste es gehen. Außerdem reden wir hier von mickymaus Programmen, denke ich.
Wenn ich in einer Firma sitzen würde, würde ich es auch nicht so machen. Aber man sollte zumindest mal die Alternative mit ihren Gefahren kennen.
Von daher ist dieser Thread gar nicht so schlecht.
Yunky: was fürn operator muss ich den nehmen wenn ich sagen will nichtgrößergleich??
Yunky: !>3??
Yunky: !≥ ??
Puppetmaster: G
Yunky: aja ka
Puppetmaster: kleiner (<)
Yunky: stimmt^^
Hallo Puppetmaster,
nee, prinzipiell falsch ist es nicht. Es ist wie immer eine Frage, ob man weiß, was man tut. Nur sage ich mal so: jemand, der DoEvents einsetzt, weil es damit schön einfach ist und das Programm auf den ersten Blick läuft, wird eben meistens nicht wissen, was man tut. Dann lieber gleich Threads empfehlen, denn da ist so ziemlichen jedem klar, dass er aufpassen muss.
herbivore
ok. Dann sind wir uns ja einig.
Yunky: was fürn operator muss ich den nehmen wenn ich sagen will nichtgrößergleich??
Yunky: !>3??
Yunky: !≥ ??
Puppetmaster: G
Yunky: aja ka
Puppetmaster: kleiner (<)
Yunky: stimmt^^