Konvertieren von ehemaligen Visual-Basic-Projekten nach VB.NET
Wann auch immer Sie im Internet einen Converter finden, der scheinbar Visual-Basic-Programme in C# übersetzt, seien Sie mißtrauisch und prüfen Sie erst mal, ob hier nicht VB.net gemeint ist, welches nach C# konvertiert wird. VB.net in C# zu übersetzen ist kein Problem.
Natürlich, es gibt eine ganze Menge an Tools und Hilfsprogrammen, mit denen man sich die Sache vereinfachen kann. Manches kann man mit einem “cleveren und gut gesteuerten” Cross-Coding erledigen. Das bedeutet: Man startet ein Programm, dass mehr oder weniger vollautomatisch aus dem VB 6.0-Programm ein .NET-Programm erstellt. Allerdings kann ich hier kaum ein Produkt auf dem Markt empfehlen. Im Kern ist es ein “programmierbarer Editor”, der sogar anpassbar sein muss an Ihren Code und an Ihre Programmkonventionen.
Beispiel: Die Software läuft später auf einer völlig anderen Hardware
In einem Forum wird zum Beispiel gefragt:
Gibt es eine Möglichkeit, eine VB6-Software auf einem Handy mit Mobile 6.1 zum laufen zu bringen?
Meine Antwort lautet: Unter VB 6.0 wird das vermutlich nicht mehr gehen, ganz einfach weil im allgemeinen dort zu viel Code an der VB-Runtime vorbei programmiert wurde. Die Tipps und Tricks auf ActiveVB zeigen recht deutlich, was ich meine. Diese sind Workarounds aufgeliste wie zum Beispiel die blinkende Titelleiste, die einen Zugriff enthält auf die Windows-API-Funktion “FlashWindow”.
Die API (für engl. application programming interface, deutsch: „Schnittstelle zur Anwendungsprogrammierung“) ist dabei aber ein Interface, dass zwar auf jedem Desktop-Windows bisher noch zur Verfügung steht. Ob das bei einem Handy mit vorinstalliertem .net-Framework auch der Fall ist, das möchte ich einfach mal bezweifeln, bzw. inzwischen jedenfalls lautstark verneinen. Hier bleibt nur die Konvertierung auf .net resp. Java.
Um zu zeigen, wie umfangreich sich der Code teilweise ändert, einfach ein Beispiel.
Beispiel: Die Stoppuhr in Visual-Basic und VB.NET
Eine Stoppuhr ist von der Funktion her recht einfach zu realisieren:
- man ließt zu zwei Zeitpunkten die Uhrzeit des Systems aus und bildet die Differenz
- man startet einen Zähler, den man irgendwie mit einem Sekundentakt synchronisieren muss oder der unsynchronisiert läuft und später kalibriert wird
Beide Verfahren haben Vor- und Nachteile. So muss man im ersten Fall klar verhindern, dass während der Laufzeit des Stoppuhrprogramms die Uhrzeit umgestellt wird und im zweiten Fall ist es zum Beispiel wichtig, dass der Rechner nicht abschaltet und in den Sleep-Modus geht – während der Messung. Weitere Probleme kommen hinzu, da es Rechner gibt, die bei höherer Belastung mit einer höheren Taktrate arbeiten.
Ein einfaches Beispiel eines inkrementierenden Zählers wäre der folgende Tipp von ActiveVB. Hier geht es um die Zeitmessung, die man in Visual-Basic 6.0 mit einer Auflösung von 0,00083 ms erfassen kann. Das verlinkte Beispiel zeigt eine Lösung, in der eine Klasse mit dem Namen “Timer” erstellt wird, die einmal die Windows APIs QueryPerformanceCounter und QueryPerformanceFrequency nach außen kapselt und einen Routinensatz bereitstellt zur Kalibrierung der Zeitmessung. Die öffentlichen Methoden der Klasse Timer sind
- .Calibrieren – was besagt, dass die Verwaltungsarbeit des Kalibrierens noch außerhalb von timer geschieht
- .Start – eine Routine, die die Zeitmessung startet
- .Halt – eine Routine, die die Zeitmessung anhält
- .ShowTime eine Routine, die die Vergangenen Millisekunden ausgibt eben mit einer Auflösung von 0,00083 ms.
Man benötigt man detailiertes API-Wissen, um diese beiden Routinen unter Visual-Basic nutzen zu können. Trotzdem sind mit diesem Zähler nur ein geringer Teil der Probleme gelöst. Ein Hauptproblem ist die CPU-Last, die durch seinen Betrieb erzeugt wird.
Unter .NET geht man anders an das Problem heran. Ohne Systemkenntnisse kann man die Stoppwatch-Klasse aufrufen. Mit “Dim SW As Stopwatch = Stopwatch” kann man eine Instanz der Klasse Stopwatch anlegen und dann kann man die Zählung mit Stopwatch.StartNew starten. Will man die Messung stoppen, ruft man SW.Stop() auf. Und mit SW.ElapsedMilliseconds ließt man die Zahl der Millisekunden aus. Spätere Entwicklungen könnten hier auch die Methode SW.ElapsedMicroseconds hinzufügen, die nur da zur Verfügung steht, wo auch die Hardware eine entsprechende Infrastruktur bereit stellt.
Die Stopwatch-Klasse steht in C# genauso zur Verfügung wie in VB.net oder in php.net. Die Umgebung der Stoppwatch-Klasse riecht also einmal etwas mehr nach Visual-Basic, einmal nach C und einmal nach php. Das eigentliche Problem allerdings ist gelöst, bzw. die Verantwortung der Lösung ist an Microsoft übertragen worden. Microsoft muss sich nun überlegen, was passiert, wenn man den Rechner während der laufenden Stoppuhr schlafen schickt oder wenn während der laufenden Stoppuhr die Uhrzeit aktualisiert wird.
Deshalb: Für Sie als Programmanwender gilt: Gehen Sie zurück zu Ihren Anforderungen, überarbeiten Sie diese und erstellen bzw. entwickeln Sie ein neues Programm. Sie brauchen nicht so viel Zeit wie Sie für die Visual-Basic-Lösung brauchten und Sie brauchen etwas mehr als beim 1:1-Übersetzen. Aber dafür haben Sie dann wirklich ein modernes Produkt, dass mit der Hardware mitwächst.
Falls Sie ein Programm zu konvertieren haben, sprechen Sie mich ruhig an.