Grundsätzliches zu Application.DoEvents in der Ereignis-Steuerung

  • VB.NET

Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von VaporiZed.

    Grundsätzliches zu Application.DoEvents in der Ereignis-Steuerung

    Hallo zusammen,

    ich möchte hier eine grundsätzliche Diskussion zu dem Thema Application.DoEvents anregen, um ggf. neue Strategien im Programmablauf zu erfahren und zu verstehen.
    ... es ist für mich befremdlich, wenn Fragesteller als "dumm oder faul" bezeichnet werden, nur wenn dieser Befehl verwendet wird.

    M.E. hilft dieser Befehl, um Ereignis-Handler kontrolliert abarbeiten zu lassen.

    Meine Strategie (bisher) lautet wie folgt (ich nehme Anregungen aber gern entgegen):

    VB.NET-Quellcode

    1. Private nicht_verarbeiten as Boolean
    2. Sub Form_Load() Handles Meine_Form.Load
    3. nicht_verarbeiten = True
    4. 'Anzeige von Daten in Textfelder
    5. '...
    6. Application.DoEvents() 'alle TextChanged-Ereignisse verarbeiten ... werden abgewiesen wg. nicht_verarbeiten = True ?
    7. nicht_verarbeiten = False
    8. End Sub
    9. Sub Textfeld_TextChanged(sender As Object, e As EventArgs) Handles Textfeld.TextChanged
    10. If nicht_verarbeiten =True then Exit Sub
    11. nicht_verarbeiten = True
    12. 'Daten speichern
    13. '...
    14. nicht_verarbeiten = False
    15. End Sub


    Meine Frage: Warum ist die Verwendung von Application.DoEvents in diesem Beispiel nicht nötig ? ... ich verstehe es noch nicht, möchte es aber gern.
    ... gibt es hier eine andere Strategie / Herangehensweise ?

    Bsp. 2: Ich möchte unterbinden, dass das Form.Activated-Ereignis nach einer MsgBox behandelt wird (zumindest in der alten Welt vor .NET war dieses der Fall)
    ... auch hier hilft mir m.E. die Behandlung via Application.DoEvents (nicht_verarbeiten = True), damit eventuelle Abfragen in Activated unterbunden werden.


    Ich bin sehr offen für Anregungen.
    .. auch um zu verstehen, wann Application.DoEvents nicht greift.
    @Datenlogistik Die Verwendung von DoEvents() in Deinem Beispiel ist nicht "nicht nötig", sondern auch völlig falsch.
    DoEvents() arbeitet die MessageQueue ab.
    Im Form_Load-Event ist die Form noch gar nicht dargestellt, Controls sind disabled und es passiert eigentlich nix.
    Dein Flag nicht_verarbeiten wird in Form_Load gesetzt und zurückgenommen.
    Sollte die Prozedur Textfeld_TextChanged in Form_Load aufgerufen werden, und sollte danach eine andere Prozedur gleicher Philosophie aufgerufen werden,
    hat das Flag nicht_verarbeiten den falschen Wert.
    Mach es so:

    VB.NET-Quellcode

    1. Private nicht_verarbeiten as Boolean
    2. Sub Form_Load() Handles Meine_Form.Load
    3. nicht_verarbeiten = True
    4. 'Anzeige von Daten in Textfelder
    5. '...
    6. nicht_verarbeiten = False
    7. End Sub
    8. Sub Textfeld_TextChanged(sender As Object, e As EventArgs) Handles Textfeld.TextChanged
    9. If nicht_verarbeiten Then Return
    10. 'Daten speichern
    11. '...
    12. End Sub
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Minimaltipp: Bei verneinenden Namen (egal, ob Variablen, Prozeduren, …) sollte immer überprüft werden, ob eine Namens- und Logikinvertierung möglich ist. Denn spätestens bei auftretenden Doppelverneinungen (was eigentlich nicht vorkommen sollte, aber alles schon gesehen), wird's übel: If Not nicht_verarbeiten = False Then. Denn bei Invertierung und Kürzung ist es dann nur noch: If Not verarbeiten Then
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()