Announcement

**lyncke** · 10.09.2007, 11:40

Nachtrag Netcoole - Turnsharp

Noch ein Nachtrag:

Da man ja besser vorsichtig formulieren muss, w�rde ich sagen: Das Delphi-C#-Konvertiertool Turnsharp ist ein preiswertes Tool, das sicherlich zu irgendwas gut ist, zur Konvertierung von Quelltext aber eher weniger.

Sollte jemand ein Alternativ-Tool zu Netcoole Delphi2CS kennen, bitte melden!

**Frank Kneffel** · 28.11.2007, 08:01

Welche Erfahrung hast Du denn mit Delphi2CS gemacht ?

**lyncke** · 20.02.2008, 13:46

Mein Erfahrungsschatz zu Netcoole Delphi2CS

Delphi2CS ist ein brauchbares Tool, um Delphi-Quelltexte zu konvertieren!

Besonders beeindruckend finde ich dabei:

1. �ber das gesamte Projekt hinweg werden alle Namen auf Gro�- und Kleinschreibung angepasst, damit C# keine Probleme damit hat. Aus diesem Grund ist es sinnvoll, f�r die Konvertierung alle zusammengeh�rigen DLLs und Packages in einem Projekt zusammenzufassen.

2. Alle selbst geschriebenen Klassenstrukturen, Records, Interfaces, Enumerators werden 100% richtig nach C# �bertragen. Hier ist keinerlei Nacharbeit n�tig! (Achtung: Das gilt nicht f�r abgeleitete VCL-Objekte! S.u.)

3. Bitmap-Operationen werden korrekt konvertiert.

Nacharbeit erfordert alles, was auf Delphi-Bibliotheken zugreift:

1. Oberfl�chen werden einigerma�en korrekt �bertragen. Meistens mu� man einparr bestimmte Eigenschaften korrigieren, dann kann Fenster in C# dargestellt werden. Oft sind es immer die gleichen Dinge! Z.B.
xControl.Align := alClient;
muss immer manuell in
xControl.Dock = DockStyle.Fill;
ge�ndert werden.

2. TabControl: Zu TTabControl gibt es kein Pendant in Winforms!! TPageControl ist OK!

3. TStringList wird immer als System.Collections.Specialized.StringDictionary �bersetzt. Dieses Objekt ist aber viel zu m�chtig und umst�ndlich. In 99% der F�lle sollte StringDictionary durch System.Collections.Generic.List<string> oder einfach string[] ersetzt werden.

Sonstige Nacharbeiten:

1. Bei mehereren Konstruktoren macht der Konvertierer immer den gleichen Fehler: Er schriebt nicht :base(x,y,z), sondern :this(x,y,z). Einfach this in base �ndern, fertig!

2. C# nimmt es �bel, wenn eine abgeleitete Klasse keinen Konstruktor und die basisklasse eine K. mit mehreren Params hat. Dann mu� man einen leeren Konstruktor definieren

3. Free-Aufrufe werden nicht konvertiert, weil in C# die GarbageCollection daf�r zust�ndig ist. Man kann eigentlich alle Free-Aufrufe l�schen. Destruktoren, die nur Free-Aufrufe enthalten, kann man auch l�schen. try-finally-Bl�cke mit der einzigen Aufgabe, Free aufzurufen, auch.

4. Ein "billiges overload" mit procedure XY( a: boolean = false) ist in C# unbekannt. Dort m�ssen alle M�glichkeiten einzeln als �berladene Funktionen nachgetragen werden.

Wichtig ist, dass einem die Unterschiede zwischen Delphi und C# klar sind, dann kann man bereits in Delphi bestimmte Konstukte vermeiden, die einem die Konvertierung versauen:

1. Niemals selber VCL-Objekte ableiten. Das kann nicht konvertiert werden.

2. Mehr drauf achten, ob ein Parameter out oder var ist. Im Zweifelsfall immer out!!! Der C#-Compiler l��t es nicht durchgehen, wenn ein ref(var)-Parameter nicht initialisiert ist.

3. Integer-Typen werden nicht automatisch ineinander konvertiert. Das kostet viel Zeit bei der Nachbearbeitung. Am besten immer nur "integer" benutzen! ShortInt, Word, Cardinal und �hnlichen Quatsch sollte man nur dann verwenden, wenn es zwingend notwendig ist.

4. Pro Klasse darf es nur eine indizierte property geben. Diese sollte man bereits in Delphi als "default;" kennzeichnen und ohne Bezeichner verwenden.

5. TQuery, TTable, TIniFile machen viel �rger bei der Konvertierung. Am besten, man reduziert Zugriffe auf diese Objekte durch Kapselung.

Was wirklich nervt und viel Zeit kostet:

1. F�r viel Spa� sorgt folgender Unterschied: Bei Delphi hat der erste Buchstabe eines strings den Index 1, bei C# den Index 0. Leider wird dieser Umstand von Delphi2CS nicht ber�cksichtigt. Also: alle string-Operationen pr�fen!

2. Die Funktion SysUtils.Format() wird nicht konvertiert. Alle Aufrufe dieser Funktion m�ssen von Hand konvertiert werden.

3. ref und out m�ssen in C# auch in die aufrufendene Funktion geschrieben werden. Das tut das Programm leider nicht (Ich hoffe auf die n�chste Version).

-------------------------------

Das soll erst mal reichen. Wenn jemand mehr wissen will, kann ich noch mehr berichten.

**Frank Kneffel** · 31.03.2008, 14:33

Danke noch einmal f�r den Erfahrungsbericht

**peter.goessweiner** · 09.03.2009, 11:22

Delphi2Cs

Hallo!

Ich besch�ftige mich auch grad mit dem Thema und m�chte meine Delphi Projekte in C# konvertieren.

Ist die im Laufe der Zeit noch etwas wichtiges aufgefallen bzw. hast du ein anderes Tool gefunden, womit die Konvertierung noch besser geht bzw. Delphi2CS unterst�tzen k�nnte? Wie siehts eigentlich mit Datenbank-Verbindungen aus?

Herzlichen Dank schon mal und

lg

Peter

**J�rgen Thomas** · 09.03.2009, 12:39

Hallo Peter,

unabh�ngig davon, was die Erfahrungen mit Konvertierungs-Tools zeigen, muss ich Dich warnen: Der DB-Zugang ist unter NET komplett anders geregelt als unter Delphi. Beispielsweise wird eine DbConnection immer nur kurzfristig f�r einen Vorgang erstellt, ge�ffnet und sofort wieder geschlossen und gel�scht; dazu wird sie am besten in einen using-Block gekapselt. Ich kann mir nicht vorstellen, wie ein Datenmodul mit permanenter Connection in eine solche Klasse konvertiert werden kann.

Gehe deshalb lieber davon aus, dass alle DB-Zugriffe manuell neu programmiert werden m�ssen. J�rgen

**peter.goessweiner** · 09.03.2009, 18:36

DB - Connections

Hallo!

Schade, aber danke f�r die Info!

Ich habe mir inzwischen selber ein eigenes Tool geschrieben, dass kleinere �nderungen* macht und ich nach Delphi2CS dr�ber laufen lasse.

* �nderungen:

- .Color = 094304; -> .Color = System.Drawing.Color.FromArgb(094304);
- systemtime -> DateTime
- GetWindowsDir -> Environment.GetEnvironmentVariable("windir", EnvironmentVariableTarget.Machine)
- SW_SHOWNORMAL -> (ushort)System.Diagnostics.ProcessWindowStyle.Norm al
- Font.Color -> ForeColor
- Application.Terminate -> Application.Exit()

Bin derzeit dabei, meine Library st�ndig zu erweitern, damit das Tool sinnvoll eingesetzt werden. Derzeit bin ich schon recht zufrieden -> Alleine die Eigenschaft ".Color = 094304" h�tte ich dutzende Male nachziehen m�ssen, was ich mir mit meinem Tool erspart habe.

Falls jemand weitere �nderungen wei�, welche nicht durch Delphi2CS abgedeckt werden, w�rde ich mich �ber ein Nahrung f�r meine Library freuen.

Wenn ich wieder mehr Eintr�ge habe, dann poste ich weitere Details (wenn gew�nscht)

lg

Peter

**lyncke** · 15.06.2009, 16:46

Hallo,

f�r den Datenbankzugriff haben wir eine Wrapper-Klasse geschrieben, die die TQuery-Klasse kapselt. Die Implementierung in C# ist zwar komplett anders, aber alle Methoden, die den Wrapper benutzen, werden korrekt �bersetzt.

Oberfl�chen, die auf Datenbank-Objekte zugreifen, sollte man am besten komplett neu schreiben, da lohnt der �bersetzungsaufwand nicht!

F�r alle, denen systematische Fehler wie z.B. .Color = 094304 -> .Color = System.Drawing.Color.FromArgb(094304) auffallen: Scheut Euch nicht, diese Erkenntnisse an Netcoole zu schreiben! Pan von Netcoole freut sich immer sehr, wenn einem solche Dinge auffallen, und versucht, sie innerhalb weniger Tage zu fixen.

Gru�

**lyncke** · 15.06.2009, 16:59

Hallo Peter,
genial w�re, wenn Dein Tool Formatstrings korrekt �bersetzen k�nnte! (Das will Pan von Netcoole n�mlich nicht.)
Ich meine damit z.B. wenn Dein Tool den Ausdruck
SysUtils.Format('Plate: %s, Width %.2f mm', [Name, Width] );
�bersetzen k�nnte in
string.Format( "Plate: {0}, Width {1:F2} mm", Name, Width );

Gru�
Wolfgang

Announcement

Quelltext-Konvertierung delphi -> C#

Quelltext-Konvertierung delphi -> C#

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment