Debug Form erstellen

  • VB.NET

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

    Debug Form erstellen

    Hallo Forumsgemeinde,
    ich wollte für eine Applikation (TCP Server/Client) eine Art Debug Form machen.
    Auf dieser sollen dann nachher ein paar 'Spezialfunktionen' und ganz wichtig eine Textbox sein.
    Nun habe ich die einzelnen Streamüberwachungen ja in verschiedenen Threads.
    Wie bekomme ich es nun hin aus allen Stellen meines Programmes Nachrichten an die Textbox in der Debug Form zu senden.

    Was wäre da eine gute Lösung?

    Kiter20
    "Mann" lernt mit seinen Projekten.
    eine Möglichkeit sind Events: ein Objekt feuert ein Event und Dein Form fängt es auf und verarbeitet es.
    Wenn die Threads innerhalb der Form-Klasse sind, geht auch Me.BeginInvoke(Sub() DeineTextBox …)
    Oder Du gibst Dich damit zufrieden, dass alles in einem Konsolenfenster auftaucht, dann Console.WriteLine("Deine Nachricht")
    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.
    @kiter20 Die Console-Ausgabe macht Sinn, denn da musst Du keine explizite Form erstellen, die im Release-Fall trotzdem vorhanden ist.
    Häng im Debug-Fall eine Console an: Kommunikation zwischen Console und Form
    und bediene sie mit Console.WriteLine(..).
    Allerdings musst Du dann noch verhindern, dass die Console direkt geschlossen werden kann, weil da das anhängende Programm mit geschlossen wird:
    Angehängte Console kann nicht direkt geschlossen werden.
    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!
    8| gehört eigentlich zum Grundlagenwissen. Aber z.B. EdR hatte da mal was: Alles über Events
    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.

    kiter20 schrieb:

    Somit würde ich den Weg über Events gehen.
    Die Console kannst Du selbstverständlich auch in der Release anhängen. ;)
    Die Console muss nicht invoked werden und ist immer von überall aus dem gesamten Projekt ansprechbar.
    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!

    RodFromGermany schrieb:

    Die Console-Ausgabe macht Sinn, denn da musst Du keine explizite Form erstellen, die im Release-Fall trotzdem vorhanden ist.


    Ich muss Rod zustimmen. In diesem Fall macht eine Konsolenausgabe definitiv mehr Sinn. Alleine weil Forms wieder mit Invoke() und/oder Threads arbeiten müssen, damit du nicht aus Versehen irgendwo deinen Server/Client blockierst.
    Eine Form geht natürlich auch und ist optisch ansprechender, allerdings bin ich (Disclaimer: ich arbeite eh lieber mit der Konsole) der Meinung, dass gerade Debuggingtools nicht zwingend für Jedermann einfach verwendbar sein müssen.

    kiter20 schrieb:

    Ich würde diese Debug Form auch im Release behalten.

    Rod hat eigentlich bereits alles hier eingefügt, was man braucht. Da würde ich an deiner Stelle mal anfangen.
    Hast du das einmal so, mit Stdin und Stdout, dann kannst du natürlich immer noch über ein T-Stück (Streams, Events, wie auch immer) eine Form nachträglich einbauen.
    Quellcode lizensiert unter CC by SA 2.0 (Creative Commons Share-Alike)

    Meine Firma: Procyon Systems

    Selbstständiger Softwareentwickler & IT-Techniker.
    Sooo, also meine Message aus den Thread wird in der 2. Form jetzt ausgegeben.
    Ich habe mich für Invoke entschieden.

    VB.NET-Quellcode

    1. Private Sub _MSG2Debug(_String As String)
    2. If FormDebug Is Nothing OrElse FormDebug.IsDisposed Then
    3. Else
    4. If Me.InvokeRequired Then
    5. Me.Invoke(Sub() _MSG2Debug(_String))
    6. Return
    7. End If
    8. FormDebug.lstDebugOutput.Text &= _String & vbCrLf
    9. End If
    10. End Sub


    Natürlich habe ich einfach C&P gemacht. Deswegen wollte ich das einmal hinterfragen.
    So wie ich das verstehe, prüft ja Me.InvokeRequired ob sich der Sender in einem anderen Thread befindet.
    Ist dem so, dann wird quasi durch Me.Invoke(Sub() _MSG2Debug(_String)) das Ding glattgezogen und durch den Aufruf von sich selber ist dann alles wieder im gleichen (Main) Thread.

    @Coldfire Es geht ja nicht nur um die reine Ausgabe/Überwachung des Streams. Deswegen @siycah auch keine Konsole.
    Ich werde in der DebugForm auch andere Funktionen noch benötigen. Quasi eine manuelle Notfall Bedienung... nur für den Fall.
    Aber definitiv habt ihr nicht unrelevante Gründe für für die Konsole gegeben.

    Persönlich finde ich aber eine Form angenehmer.

    Ein zusätzlicher Aspekt ist, das Umfeld in dem die Software eingesetzt wird und wer diese Bedient.
    Ich selber arbeite im Maschinebau in der Inbetriebnahme für Bearbeitungszentren. Ich arbeite eng mit SPS Programmierern und Software Entwicklern zusammen.
    Es gibt quasi überall eine Art DebugForm, einfach um zu sehen was das Programm macht.
    Der Kunde für den diese Software ist, wird in der Lage sein, die Informationen aus der DebugForm zu interpretieren und mir schon im Vorfeld eine Problem Beschreibung per Mail senden können.
    "Mann" lernt mit seinen Projekten.
    Ich bin ja überhaupt kein Fan von leeren If-Blöcken, ich bevorzuge:

    VB.NET-Quellcode

    1. Private Sub _MSG2Debug(_String As String)
    2. If FormDebug Is Nothing OrElse FormDebug.IsDisposed Then Return
    3. If Me.InvokeRequired Then
    4. Me.Invoke(Sub() _MSG2Debug(_String))
    5. Return
    6. End If
    7. FormDebug.lstDebugOutput.Text &= _String & vbCrLf
    8. End Sub

    Dann ist die Frage, ob das Ganze überhaupt außerhalb eines Nebenthreads aufgerufen wird. Falls es nur in Nebenthreads aufgerufen wird, dann:

    VB.NET-Quellcode

    1. Private Sub _MSG2Debug(_String As String)
    2. If FormDebug Is Nothing OrElse FormDebug.IsDisposed Then Return
    3. Me.Invoke(Sub() FormDebug.lstDebugOutput.Text &= _String & vbCrLf)
    4. End Sub

    Statt Invoke geht auch BeginInvoke, aber der Zeitunterschied dürfte irrelevant sein.
    Unterschied:
    • Invoke: Mach etwas und warte, bis es fertig ist.
    • BeginInvoke: Mach und warte nicht, bis es fertig ist, sondern mach gleich weiter mit der nächsten Anweisung.
    Wenn FormDebug ein instanziiertes SubForm ist, ok. Wenn es nur ein Klassenname ist, dann bitte nicht.
    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.

    VaporiZed schrieb:

    If FormDebug Is Nothing OrElse FormDebug.IsDisposed Then Return

    Stimmt. Kam ich irgendwie in dem Moment nicht drauf.

    Dann ist die Frage, ob das Ganze überhaupt außerhalb eines Nebenthreads aufgerufen wird

    Ja. In der MainForm ist die Sub, welche auf der FormDebug in die Textbox schreibt.
    Aufgerufen wird es aus einen "Listen" thread, wo ich dann zu debug Zwecken alles was über den StreamReader reinkommt zusätzlich in der DebugForm ausgeben kann.

    Wenn FormDebug ein instanziiertes SubForm ist, ok.

    Muss es doch, sonst habe ich das doch gar nicht richtig unter Kontrolle. Oder sehe ich das verkehrt.
    Ich meine damit: Ich erstelle es und kenne es. Sonst muss ich mir das doch wieder irgendwo die Instanz herholen.
    "Mann" lernt mit seinen Projekten.

    kiter20 schrieb:

    In der MainForm ist die Sub, welche auf der FormDebug in die Textbox schreibt.
    Aufgerufen wird es aus einen "Listen" thread
    Dann kannst Du das mit dem InvokeRequired weglassen und den 2-Zeiler / letzten Codeblock aus Post#10 nehmen, da der Invoke ja immer gebraucht wird, da die Sub nur im Nebenthread aufgerufen wird.

    kiter20 schrieb:

    Muss es doch
    Naja, das ist nicht allen VB-Programmierern klar 8| . Aber freut mich zu lesen, dass es für Dich eine Selbstverständlichkeit ist :)
    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.