Hi

In meinen Augen ist DoEvents() sehr nützlich, um z.B. kleiner Animationen hinzubekommen, ohne dass die Form sich aufhängt.

Nun habe ich aber des öfteren gesehen, dass hier im Forum DoEvents() sofort bemeckert wird.

Nun wollte ich einfach mal Fragen:
- Was ist so falsch an DoEvents()?
Bitte mit ordentlicher Begründung

Greetz, Marco

a) es ist nicht das "richtige" (sondern nur ein Ausweg für Faule/Dumme)
b) stackoverflow.com/questions/51…e-of-application-doevents

Auszug aus MSDN Dokumentation (, der übrigends mit einem dicken Vorsicht gekennzeichnet ist):

Das Aufrufen dieser Methode bewirkt, dass der aktuelle Thread angehalten wird, während alle wartenden Fenstermeldungen verarbeitet werden. Wenn eine Meldung bewirkt, dass ein Ereignis ausgelöst wird, dann werden andere Bereiche des Anwendungscodes möglicherweise ausgeführt. Dies kann bewirken, dass die Anwendung unerwartete Verhaltensweisen zeigt, die schwierig zu debuggen sind. Wenn Sie Vorgänge oder Berechnungen ausführen, die eine lange Zeit brauchen, ist es oft vorzuziehen, jene Vorgänge auf einem neuen Thread auszuführen. Weitere Informationen über asynchrone Programmierung finden Sie unter Übersicht über die asynchrone Programmierung.

Wenn Du willst, dass einzelne Controls refreshed werden, rufe deren Update-Methode auf, sda weißt Du genau, was passiert und auch was nicht passiert.

Unterscheidet sich DoEvents() in .NET eigentlich von DoEvents in VB 6.0? Ich verwende noch 6.0 (und verwende da auch DoEvents) und steige bald sicher auf .NET um, da schadet es sicher nicht, sich schonmal ein paar Infos zu holen.

glaub macht dasselbe.
Nur in VB6 wüsste ich garnet MultiThreading zu programmieren.

Ich hab in VB.DOS (32-Bit-Basic unter MSDOS, Nachfolger von PDS, parallel zu VB2/VB3-16 Bit) mit DoEvents "ButtonKlick"-Ereignisse abgefragt.

ErfinderDesRades schrieb:

Nur in VB6 wüsste ich garnet MultiThreading zu programmieren.

Geht da auch, aber nicht von Haus aus, nur umständlich über Windows-APIs.

Demnach ist Multithreading das neue DoEvents.

Marcus Gräfe schrieb:

Demnach ist Multithreading das neue DoEvents.

Eher nein.
MyControl.Update() trifft es eher, denn das DoEvents wurde hauptsächlich zum Neuzeichnen der Form verwendet.

@Marcus Gräfe
@RodFromGermany
@ErfinderDesRades
@picoflop

Hmm.. Gibt es denn alternativen zu Application.DoEvents()?

Also wenn ich z.B. ein Control nach links bewege und gleichzeitig soll man alles andere weiterbenutzen können.
Wie mache ich das dann?

Aus einem anderen Thread kann man ja nicht auf ein Control zugreifen.
Und wenn ich das per Invoke mache, läuft es ja doch über den Mainthread.

Threads oder nen Timer.

Und wenn ich das per Invoke mache, läuft es ja doch über den Mainthread.

Darfst ja auch nicht jede Millisekunde invoken..

Marcus Gräfe schrieb:

Demnach ist Multithreading das neue DoEvents.

nee - kannmanso nich sagn.
Ist typisch .Net: Die Konzepte sind so anders, und um Welten besser.
Also MultiThreading ist ein neues, ganz anneres und Ober-mächtiges Instrumentarium, mit dem man nebenbei auch die Probleme löst, die man annoTuck mit Application.DoEvents() gelöst hatte.

@MarcoQuinten: Animation ist generell ein Problem in Winforms - dafür isses eiglich nicht gemacht, und vonne Technik her im Grunde zu langsam.
Jo, man murkst da mit Timern herum, und kann mit OwnerDrawing noch einiges weiter herausholen, aber mit zunehmender Fläche, die zu animieren ist, und zunehmender Geschwindigkeit geht der CPU da schnell die Puste aus, unds fängt an zu flackern.

MarcoQuinten schrieb:

Aus einem anderen Thread kann man ja nicht auf ein Control zugreifen.
Und wenn ich das per Invoke mache, läuft es ja doch über den Mainthread.

Natürlich kann man das, über Delegates, dafür sind sie da um aus einem Thread auf einen anderen zuzugreifen. Das Berechnen der neuen Positon geschieht im Thread z.B. Endlosschleife mit Sleept vlt. jede Sekunde wird ein Delegate übe rInvoke aufgerufen und schickt die neuen Koordinaten an den Button. Ergebnis, der Button bewegt sich ohne das der GUI Thread einfriert.

ok danke

Marcus Gräfe schrieb:

Demnach ist Multithreading das neue DoEvents.

Nein.
Task.Yield ist das neue DoEvents
msdn.microsoft.com/de-de/libra…task.yield(v=vs.110).aspx
also FW 4.5 oder FW 4 Async Targeting Pack

siehe auch:
social.msdn.microsoft.com/Foru…81-4138-bac5-46df01f2b2cf
(Post von Stephen Toub):