Servus Tron, willkommen im Forum

Stell dir doch mal folgende frage:
Ist es Sinnvoll ein Programm laufen zu lassen, welches einen offensichtlichen und absolut grundlegenden Fehler hat?

was die "Ausgabe" angeht, sobald du dich an einem Haltepunkt befindest, solltest du in der unteren linken hälfte von VS die Fenster "local", "autos" und "watch" haben. In diesen werden dir alle relevanten variablen angezeigt, und du kannst durch sämtliche Properties und sonstige Member Blättern.
Das selbe kannst du jedoch auch tun, indem du mit der Maus, während du durch den Code steppst, über den entsprechenden Variablen hoverst. Du brauchst also nicht die "Ausgabe" betrachten, VS zeigt dir noch viel mehr.

@tron25 Willkommen im Forum.
Willkommen in der Welt der "richtigen Programmierung".
Ich weiß, dass alte Basic-Varianten liefen und an der ersten Zeile, die syntaktisch falsch sind, stehen blieben. Dies ist eine Besonderheit von Interpretern und Compretern, wo das so ist.
Ob das in VB6 so ist bzw. so sein kann, weiß ich nicht.
Lerne dies:
Jede einzelne Zeile Code, von deren Richtigkeit Du Dich nicht überzeugt hast, ist falsch Wenn Du nach Überlegung nicht geneigt bist diesem Satz zuzustimmen, bist Du arrogant und Du wirst hier wenig echte Hilfe bekommen.
Das Hilfsmittel, sich vom Funktionieren von Code zu überzeugen, ist das Debuggen (Fehlerfrei machen), gugst Du hier.
.NET stellt Compiler bereit, die den gesamten Projekt-Code compilieren, bevor er ausgeführt werden kann.
Code, der erst compiliert werden muss, bevor er ausgeführt werden kann, muss inkrementell erstellt werden
D.h., Du bist entweder so genial, dass Du 1000 Zeilen Code schreiben kannst, ohne zumindest die Compilierbarkeit zu testen
oder
Du compilierst Dein Programm nach jeder geschriebenen in sich zusammengehörigen Code-Gruppe (z.B. einen If- oder Using-Block, eine While-Schleife usw.)
Wenn Du Code von VB6 nach VB.NET übernehmen willst, musst Du etwa so vorgehen:
Erstell ein neues Projekt mit Option Strict On.
Designe die .NET-GUI nach dem Bild der alten GUI.
Übernimm die VB6-Variablen nach VB.NET, überleg Dir dabei, welchen .NET-Typ sie dann haben müssen.
Übernimm einzeln Prozeduren, die nur aufgerufen werden, nicht aber selbst noch nicht übertragene Prozeduren aufrufen (sozusagen von unten nach oben).
Teste Deinen Code nach jeder einzelnen eingefügten Prozedur.
Schreibe ggf. in eine separate Button_Click-Prozedur einen Test-Aufruf für diese Prozeduren, beachte dabei, dass gewisse Startbedingungen erfüllt sein müssen.
Wenn der Test erfolgreich verlief, übernimm die nächste Prozedur.
Achtung:
Das Arbeiten mit GUI-Controls unter VB.NET ist völlig anders als unter VB6
Wenn Du ein klar umrissenes Teilproblem hast, löse dies in einem separeten .NET-Projekt und übernimm dann den fertigen getesteten Code in Dein Hauptprogramm.
Viel Erfolg.

@tron25 Während des Debuggens werden die Controls der GUI nicht refreshed.
Um beim Debuggen zu sehen, was auf dem Bildschirm steht, empfiehlt sich ein zweiter Bildschirm. Auf dem einen läuft die zu debuggende Form, auf dem anderen die Entwicklungsumgebung.
Setze einen Haltepunkt in Dein Programm.
Wenn das Programm bei diesem Haltepunkt stoppt, ist die GUI aktuell. Wenn Du nun schrittweise Dein Programm abarbeitest, werden Änderungen an der GUI nicht (vollständig) nachgezogen, insbesondere wird das Malen in einer Paint-Anweisung nicht dargestellt.