Hallo Zusammen,

ich etwickle seit mehreren Jahren mit Delphi5 und möchte auf .NET umsteigen. Macht es Sinn sich mit dem gewohnten VCL zu beschäftigen oder sollte man gleich auf MFC-Forms umsteigen?

Gruß Gitta

Moderiert von Tino: Überflüssige Zeilenumbrüche entfernt.

gitta hat folgendes geschrieben:

Macht es Sinn sich mit dem gewohnten VCL zu beschäftigen oder sollte man gleich auf MFC-Forms umsteigen?

Du meinst wohl WinForms, die recht wenig mit der MFC zu tun haben, sondern eher der VCL ähnelt.

WinForms wird mit .NET 2.0 bereits als deprecated gehandelt, weil es durch Avalon (WinFX) ersetzt wird. Die VCL.NET funktioniert dagegen nur unter Windows, erleichtert aber die Migrierung, wenn man von der VCL her kommt. Zudem ist sie schneller und an einigen Stellen Funktionsreicher als WinForms. Nutzt aber sehr viel P/Invoke (unmanaged DLL Aufrufe). Die stecken aber in WinForms genauso drinnen, nur das man sie nicht sieht, weil man den WinForms Quellcode nicht hat (auch wieder ein Pluspunkt für die VCL, da sie keine Blackbox ist).

AndyB hat folgendes geschrieben:

Zudem ist sie [die VCL.NET] schneller

Habe ich was verpasst?
Ich war immer der Meinung, daß die VCL.NET langsamer ist, gerade weil sie zu 90% aus P/Invokes besteht...

Hi AndyB,

Du hast natürlich Recht ich meinte WinForms, glaube ich zumindest.

Ja, jetzt muß ich wohl nochmal nachhaken: Ich dachte WinForms sind komplett .NET und die VCL ist irgendwie angepasst worden, aber kein reines .NET.

Wenn nun in .NET 2.0 WinForms abgekündigt werden würde, dan macht es ja keinen Sinn WinForms zu verwenden. Jetzt Blicke ich garnichtmehr durch.

Du schreibst noch das die VCL.NET nur unter Windows leuft, ist eigentlich klar das ist doch auch so bei WinForms oder wird jetzt WinFX auch andere Platformen unterschtützen?

Gruß Gitta

Moderiert von Tino: Überflüssige Zeilenumbrüche entfernt.

gitta hat folgendes geschrieben:

Ich dachte WinForms sind komplett .NET und die VCL ist irgendwie angepasst worden, aber kein reines .NET.

Unter Windows98/ME/NT/2000/XP gibt es nur die Win32API als Grundlage. Und auf der muss .NET aufbauen. Solange nur Arbeitsspeicher herumgeschoben wird, kann das komplett in der .NET Umgebung geschehen. Wenn aber auf das User-Interface zugegriffen wird, kommt man um die user32.dll nicht herum, denn sonst kann man Windows nicht klar machen, dass man jetzt ein Fenster haben möchte.

Zitat:

Wenn nun in .NET 2.0 WinForms abgekündigt werden würde, dan macht es ja keinen Sinn WinForms zu verwenden. Jetzt Blicke ich garnichtmehr durch.

WinForms wird es unter .NET 2.0 auch noch geben, nur ist das bevorzugte Framework das von Windows Longhorn, also Avalon.

Zitat:

Du schreibst noch das die VCL.NET nur unter Windows leuft, ist eigentlich klar das ist doch auch so bei WinForms oder wird jetzt WinFX auch andere Platformen unterschtützen?

Unter Linux kann man mit Mono einige WinForms Anwendungen zum laufen bringen, da die Mono-Entwickler das WinForms Assembly für Linux geschrieben haben, das dann natürlich auf GTK statt auf die Win32API zurückgreift (demensprechend sieht ein solches Programm unter Linux aus)

Auf der Microsoft-Seite gibt´s eine Datei mit den .NET-APIs, die beim Final-Release von .NET 2.0 rausfliegen. Vom Ende von WinForms würde ich da auch noch nicht reden.

AndyB hat folgendes geschrieben:

Unter Linux kann man mit Mono einige WinForms Anwendungen zum laufen bringen, da die Mono-Entwickler das WinForms Assembly für Linux geschrieben haben, das dann natürlich auf GTK statt auf die Win32API zurückgreift (demensprechend sieht ein solches Programm unter Linux aus)

Nein, die Winforms sind in Mono durch eine komplett eigene Implementierung ersetzt worden. Es wird aber durch eine selbstgebastelte Themeing-Engine versucht, Win32- und GTK-Stil auf allen Plattformen zu ermöglichen.

Hallo Zusammen,

könnt Ihr Bitte für mich eine Empfälung aussprechen wie man das .NET angehen sollte? Es ist schon wichtig, zumal man ohne Fremdkomponenten eher nicht auskommt. Es gibt schon Komponenten für VCL.NET und jede Menge Win-Form Komponenten. Oder ist es einfach noch zu Früh sich mit .NET zu beschäftigen?

Gruß Gitta

Moderiert von Tino: Überflüssige Zeilenumbrüche entfernt.

Hallo Gitta,

es führt doch eh kein Weg am .Net vorbei... in Kürze wird es keine Sprache mehr geben, die nicht gezwungen wäre, es zu unterstützen. (Sogar Powerbuilder in der Version 10 unterstützt .Net) Und bald gibt es nichts anderes mehr, weil Microsoft dominiert. Also warum mit alten Methoden neue Software schreiben ?

Ich unterstütze nur noch in alten Projekten alte Techniken. Alle neuen Projekte werden in .NET geschrieben, momenatn in Delphi 2005 oder Visual Studio Architect 2003.

Der Vorteil ist : Das ist alles plötzlich das selbe.. Ich merk schon gar nicht mehr ob ich in c# , Delphi oder Visual Basic programmiere, weil .NET ein Framework ist und sich sozusagen in die jeweilige Sprache integriert...

Man hat kein Problem irgendwelche Beispiele in die jeweilige, benutzte Sprache zu übertragen.

Ich kann .Net nur empfehlen, wie gesagt, es führt eh kein Weg daran vorbei und die Bedienung ist denkbar einfach. Nur... alte Software umbauen... vergiss es. Das wird nix. Aber für alle neuen Projekte macht's echt Spass und hat tolle Features.

Gruß

PS: Eigentlich war ich mal ein .NET Hasser und hab mich lange gesträubt...
Aber zwischenzeitlich 'liebe' ich es ...

Moderiert von Tino: Überflüssige Zeilenumbrüche entfernt.

Ich habe mich auch ein wenig mit .NET beschäftigt.
Nach einer ersten positiven Überraschung kam die Ernüchterung.

Datenbankanwendungen mit .NET (ADO.NET) haben mich nicht überzeugt. Deswegen schiebe ich das jetzt vor mir her. In dem Bereich muss wirklich noch was getan werden. Das ist viel zu umständlich.

Andere Sachen sind dagegen wirklich einfacher geworden.
Ein kleines Programm um Prozesse zu verwalten ist fast Kleinkram.

Alles auch schön objektorientiert. Allerdings ist .NET so umfangreich, dass man sehr schnell den Überblick verliert. Nicht nur das! Wenn man nach einer speziellen Funktionalität sucht, die mit Sicherheit irgendwo existiert, ist die Hilfe auch nicht besonders hilfreich. Man muss schon den Namen kennen.

Zitat:

Datenbankanwendungen mit .NET (ADO.NET) haben mich nicht überzeugt. Deswegen schiebe ich das jetzt vor mir her. In dem Bereich muss wirklich noch was getan werden. Das ist viel zu umständlich.

Würde ich jetzt nicht sagen, dass Datenbanken schwerer geworden sind. Kommt ganz darauf an, wie man Sie anspricht. Ich benutze grundsätzlich keine Bindungen oder irgendwelche Komponenten oder Assistenten... Ich finde die Möglichkeiten des Zugriffs einfacher. Natürlich muss man etwas umdenken, aber das ist mir innerhalb von 2 Tagen ganz gut gelungen.

ist echt Gewöhnungssache. Wenn man vorher schonmal mit ADO gearbeitet hat ist's easy... Bau Dir einfach ein paar Funktionen, die alles für Dich erledigen...

Zitat:

Nicht nur das! Wenn man nach einer speziellen Funktionalität sucht, die mit Sicherheit irgendwo existiert, ist die Hilfe auch nicht besonders hilfreich.

Nicht in der Delphi-Hilfe, dass stimmt. Allerdings gibt es unzählige, gute Beispiele in c# und Visual Basic .NET und die, dass meinte ich vorher, sind gaaaaanz einfach umzusetzen ! Oder benutzt, so wie ich die MSDN-Library. Die ist richtig Geil ! Da steht alles drin.

PS: Wenn ich dran denke... vor 10 Jahren, Microsoft SQL-Server und Visual Basic und ODBC urgh ! Rette sich, wer kann... oder Delphi 1.0 und MS-SQL ! Urgh ! In Anbetracht dessen finde ich .Net /ADO.NET echt einfach und logisch...

Moderiert von Tino: Überflüssige Zeilenumbrüche entfernt.

Also zu den Datenbankverbindungen mit ADO:

habt ihr schonmal an nHibernate gedacht??? Ich habe es zwar noch nicht getestet, hab aber bei meiner Diplomarbeit Java mit Hibernate verwender und war davon echt begeistert...und da das nHibernate dem Hibernate aus Java nachgebildet ist, freu ich mich schon mal drauf das ganze einzusetzen