Bessere Alternative für Application.DoEvents()

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von Naifu.

    Bessere Alternative für Application.DoEvents()

    Hallo zusammen,
    Folgendes „Problem“: ich habe in einem Form mehrere Sub (Sub1a…4a) die völlig unabhängig voneinander über eine Datenschnittstelle die gleiche Anfrage (Sub_Frage()) an eine externe Hardware stellen. Unmittelbar nach der Anfrage starte ich in ‚Sub Frage()‘ einen Timer für einen evtl. Timeout bei der Antwort. Die Antwort der ext. Hardware dauert ein wenig. Dann gammelt das Programm in ‚Sub_Frage()‘ unnötig mit Application.DoEvents() in einer while() Schleife herum bis entweder die Antwort mittels Event oder der Timeout kommt. Mit der Antwort oder der Timout-Info geht es dann im Code Sub1b..4b weiter.
    Wie kann ich sowas besser lösen, ohne dieses Application.DoEvents()?
    Im Grunde brauche ich einen Mechanismus der dafür sorgt, dass das Programm an der Stelle des Sub_Frage()-Aufrufs in der jeweiligen Sub1..4 mit der Rückmeldung des Moduls fortgesetzt wird.
    Mein Ansatz war jetzt: Sub1a..4a rufen ‚Sub-Frage()‘ auf. Dort wird die Anfrage geschickt und es wird eine Variable gesetzt die vermerkt, welche der Sub1a…4a die Antwort möchte und ein Timer für den Timeout wird gestartet. Kommt die Antwort per Event und KEIN Timeout, wird in Event() geprüft welche Sub1a..4a die Frage gestellt hat und die Antwort möchte. Da Sub1a..4a nicht auf Rückmeldung von ‚Sub_Frage()‘ warten, wird die Abarbeitung der jeweiligen Antwort in einer separaten Sub1b..4b durchgeführt.

    @Naifu Jou.
    @roepke Der Thread arbeitet in einer Endlosschleife, er tut dabei nix (Leerlauf).
    Wenn Du Daten holen willst, sagst Du: "Daten holen" (z.B. über ein Flag oder einen Abfrage-String <> ""). Der Thread startet nun das Datenholen.
    Wenn die Daten da sind oder wenn Timeout vorbei ist, sendet der Thread ein entsprechendes Event und geht wieder in den Leerlauf.
    Feddich.
    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!

    Erinnert mich an mein internes TCP-Server-Client-Gebräu.
    Der Server (oder die Software Deiner externen Hardware) lungert im Hintergrund und wartet auf Input.
    Der Client (oder Dein Programm) erzeugt 2 Tasks. Einen Verbindungstask und einen Timeout-Task. Dann starte ich beide Tasks (nebenläufig) und wenn einer fertig ist, wird geschaut, was passiert ist. Kam ne Antwort oder hat der Timeout-Task seinen Job erledigt?
    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.

    Ich habe meinen doch sehr umfangreichen Code auf das wesentliche reduziert um meine Problemstellung etwas genauer erörtern zu können.

    Spoiler anzeigen

    VB.NET-Quellcode

    1. Private Sub MacheEtwas_1()
    3. 'Hier werden erst ein paar DInge erledigt, die das eigene Form betreffen
    5. If (PruefeStatus() = False) Then
    6. Call MacheDies_1()
    7. Else
    8. Call MacheDas_1()
    9. End If
    11. 'Mache hier noch mehr Dinge die das eigene Form betreffen
    13. End Sub
    15. Private Sub MacheEtwas_2()
    17. 'Hier werden erst ein paar DInge erledigt, die das eigene Form betreffen
    19. If (PruefeStatus() = False) Then
    20. Call MacheDies_2()
    21. Else
    22. Call MacheDas_2()
    23. End If
    25. 'Mache hier noch mehr Dinge die das eigene Form betreffen
    27. End Sub
    29. Private WithEvents TimeOutTimer As New System.Timers.Timer
    30. Public Delegate Sub doSub()
    31. Dim AntwortErhalten as Boolean
    32. Dim Rueckgabewert as Boolean
    34. Private Function PruefeStatus() as Boolean
    35. AntwortErhalten = False
    36. Call RunSubWithTimeOut(AddressOf LeseStatus, 2000)
    37. 'Jetzt müsste hier eigentlich ein Returnwert stehen, dessen Zustand True/False aber noch nicht bekannt ist,
    38. 'weil dieser erst von der externen Hardware angefordert werden muss.
    39. While AntwortErhalten = False
    40. Application.DoEvents()
    41. End While
    43. Return Rueckgabewert
    45. End Sub
    47. Private Sub LeseStatus()
    48. 'hier erfolgt der Leseaufruf an die externe Hardware
    49. End Sub
    51. Private Sub RunSubWithTimeOut(d As doSub, iMilliseconds As Integer)
    52. Invoke(d)
    53. TimeOutTimer.AutoReset = False
    54. TimeOutTimer.Interval = iMilliseconds
    55. TimeOutTimer.Start()
    56. End Sub
    58. 'Antwortt die Hardware nicht, erfolgt ein Timeout
    59. Private Sub TimeOutTimer_Elapsed(sender As Object, e As System.Timers.ElapsedEventArgs) Handles TimeOutTimer.Elapsed
    60. TimeOutTimer.Stop()
    61. MessageBox.Show("Timeout")
    62. End Sub
    64. 'Die Hardware hat geantwortet, es wird ein Event ausgelöst
    65. Private Sub _Event_()
    67. TimeOutTimer.Stop()
    68. MessageBox.Show("No Timeout")
    70. AntwortErhalten = True
    71. 'Empfangene Information der externen Hardware auswerten und damit letztlich in 'MacheEtwas()' klar machen, was dort weiter zu tun ist.
    72. Rueckgabewert = 'True oder False, abhängig von der Modulantwort
    74. End Sub



    Ein WindowsForm hat die Funktionen(Subs) MacheEtwas_1…_2(). Abhängig von PruefeStatus soll entweder MacheDies_1.._2() und MacheDas_1.._2() ausgeführt werden, welche im selben WindowsForm sind.

    Mein Problem ist nun, dass das Programm in PruefeStatus() so lange verweilen muss, bis klar ist, ob dieser True oder False ist. Diese Info kommt von externer Hardware, die einige Zeit benötigt um zu antworten. Diese Antwort kommt per Event.

    In MacheEtwas_1.._2() werden zum einen noch weitere Dinge im Anschluss nach If..Else..EndIf ausgeführt, noch dazu sind MacheDies_1.._2() und MacheDas_1.._2() Bestandteil des WindowsForms. Wenn ich MacheEtwas_1.._2() mittels Invoke ausführe läuft ja nur diese Funktion losgelöst vom Rest, oder? MacheDies_1.._2() und MacheDas_1.._2() sind ja nur im Haupthread was passiert bei deren Aufruf innerhalb von Invoke.

    Bzw. wie ist das dann, wenn eine per Invoke aufgerufene Funktion bei PruefeStatus() ankommt und wiederum diese Funktion startet? Wenn dies ebenfalls per Invoke geschieht, sollte es doch kein Problem mehr sein. Wenn ich das richtig verstehe, dann läuft ja im Grunde das Hauptprogramm weiter, MacheEtwas_1.._2() sind davon losgelöst. PruefeStatus() wäre das ebenfalls. D.h. wenn dort ein Application.DoEvents() steht, sollte es den Rest der Anwendung nicht beeinflussen. Kommt dann aber die Antwort per Event muss dieses zuvor von PruefeStatus() abonniert werden, da dies ja in einem extra Thread läuft.

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „roepke“ ()

    Iwie ist mir dein letzter Post verlustig gegangen.
    In deinem PseudoCode kann ich nicht die Problem Stellung deines erten Posts erkennen, es fehlt mir auch die HW Simulation.
    Zum Problem:
    Das Ganze soll in einem Form ablaufen?
    Jede der 4 Sub kann den HW Request auslösen?

    Als erstes benötigen wir eine HW Simulation in Form einer klasse, die Verzögerung kannst du mit einem Timer realisieren.
    Ist der Timer fertig dann löst das einen event aus.
    Das Ergebnis des HW Request packst du in eine eingen Klasse die von EventArgs erbt und im Event übergeben wird.
    Die Klasse würde ich HWSim taufen.
    Die sollte eine Sub Namens Request haben.
    Den Event könnte man Response benamen.
    Und ResponseEventArgs für die die Daten.
    Mach mal und poste den Code der Simulation.
    Dann sehen wir weiter. ;o)

    Keine Antwort, scheint ja nicht so wichtig zu sein.
    Habe dir mal was zusammen gestrickt.

    VB.NET-Quellcode

    1. ​Public Class Form1
    2. Private HWSimu As New HWSim
    3. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    4. HWSimu.Request(AddressOf Sub1)
    5. HWSimu.Request(AddressOf Sub2)
    6. HWSimu.Request(AddressOf Sub3)
    7. HWSimu.Request(AddressOf Sub4)
    8. End Sub
    10. Private Sub Sub1(sender As Object, e As EventArgs)
    11. Dim hw As HWSim = DirectCast(sender, HWSim)
    12. MessageBox.Show("Sub1" & vbCrLf & hw.Data)
    13. End Sub
    14. Private Sub Sub2(sender As Object, e As EventArgs)
    15. Dim hw As HWSim = DirectCast(sender, HWSim)
    16. MessageBox.Show("Sub2" & vbCrLf & hw.Data)
    17. End Sub
    18. Private Sub Sub3(sender As Object, e As EventArgs)
    19. Dim hw As HWSim = DirectCast(sender, HWSim)
    20. MessageBox.Show("Sub3" & vbCrLf & hw.Data)
    21. End Sub
    22. Private Sub Sub4(sender As Object, e As EventArgs)
    23. Dim hw As HWSim = DirectCast(sender, HWSim)
    24. MessageBox.Show("Sub4" & vbCrLf & hw.Data)
    25. End Sub
    26. End Class


    VB.NET-Quellcode

    1. Public Class HWSim
    2. Private handlerQ As New Queue(Of EventHandler)
    3. Private isRequestRunning As Boolean = False
    4. Property Data As String
    5. Private Sub [AddHandler](hEv As EventHandler)
    6. handlerQ.Enqueue(hEv)
    7. End Sub
    8. Public Sub Request(hEv As EventHandler)
    9. [AddHandler](hEv)
    10. If Not isRequestRunning Then
    11. isRequestRunning = True
    12. Dim th As New Threading.Thread(AddressOf StartReqeuest)
    13. th.IsBackground = True
    14. th.Start()
    15. End If
    16. End Sub
    18. Private Sub StartReqeuest()
    19. Dim sw As New Stopwatch
    20. sw.Start()
    21. While sw.ElapsedMilliseconds < 1000
    22. 'Warten auf die HW
    23. End While
    24. While handlerQ.Count <> 0
    25. _Data = handlerQ.Count.ToString
    26. handlerQ.Dequeue.Invoke(Me, New EventArgs)
    27. End While
    28. isRequestRunning = False
    29. End Sub
    30. End Class


    Ist nur ein Weg, das kannst du dann ja so anpassen wie du es benötigst.
    Viel Spass damit.