Zusammenfassung des Anliegens

22/02/2009 - 04:47 von Markus Schertler | Report spam
Hallo,

Herfried schrieb weiter unten:


> Doch sind die Modelle der Programmierschnittstelle unter Windows-Forms
> und
> WPF wirklich auch so unterschiedlich?

Im Detail sind sie doch sehr unterschiedlich. Sieh Dir mal an, welche
Methoden und Ereignisse die Windows-Forms-Steuerelemente besitzen. In
'OnPaint' kann beispielsweise eigener Code zum Ändern des Aussehens
basierend auf GDI und GDI+ eingefügt werden. Wie sollte man diesen Code
sinnvoll nach WPF übersetzen?



Nein. Solch ein Code braucht nicht nach WPF übersetzbar zu sein.
Solch einen Code muss man eben völlig neu schreiben, wenn man ihn wirklich
braucht...
Doch ist solch ein Code nicht sehr selten, global gesehen?

Wir zeigen in Windows Forms Fenster und Controls an, füllen diese mit
Inhalten und fragen Ereignisse ab und holen
uns die geànderten Daten.

Es geht mir darum, dass ich es schade finde dass der Aufwand der Umstellung
eines Windows Forms Programms
auf die WPF Technologie wohl so hoch ist dass man es làsst...

Das man diesen Aufwand durch bewahren einer gewissen Kompatibilitàt in der
Syntax der gàngigen Verwendung von WindowsForms
hàtte ganz ganz wesentlich begrenzen können.

Durch gleiche Namespaces mit einem anderen Vorsatz. Gleiche Klassen- und
Methodennamen für die gàngigen Properties,
Methoden und Events die wir doch in beiden Welten wohl allermeist verwenden
und brauchen.

Markus
 

Lesen sie die antworten

#1 Peter Fleischer
22/02/2009 - 09:17 | Warnen spam
"Markus Schertler" schrieb im Newsbeitrag
news:

...
Es geht mir darum, dass ich es schade finde dass der Aufwand der
Umstellung eines Windows Forms Programms
auf die WPF Technologie wohl so hoch ist dass man es làsst...



Hi Markus,
solange du dich nur im Funktionsumfang von Windows Forms bewegst, brauchst
du kein WPF. Wenn du die neuen Möglichkeiten von WPF nutzen willst, kann es
keine Konvertierung geben, da es diese Möglichkeiten in Windows Forms nicht
gibt. Niemand würde auf die Idee kommen, ein Remote-Projekt in ein
Socket-Projekt automatisch konvertieren zu wollen. Du kannst jetzt natürlich
entgegnen, dass WCF genau diese Schale bietet, um mit einer einheitlichen
Technologie beide Basistechnologien zu nutzen. Ähnliches könnte man sich
natürlich auch für Windows Forms und WPF vorstellen als beispielsweise GPF
(gràffics pràsentation faundation) :-). Über eine Config-Datei kannst du
dich dann entscheiden, ob die so oder so arbeitest. Für Windows Forms
müssten dann natürlich gewaltig viele neue Klassen erstellt werden, um auch
nur annàhernd auf dem Niveau von WPF arbeiten zu können. Ob sich der Bau
solch eines Frameworks lohnt, bezweifle ich. Ich denke nur an den Aufwand,
Daten an den Container zu binden, auf das dann alle eingebettenen
Steuerelemente zugreifen oder die Möglichkiet, Steuerelemente beliebig tief
zu schachteln. Man müsste in Windows Forms die Control-Klasse völlig anders
gestalten. Das war nur kleines Beispiel.

Das man diesen Aufwand durch bewahren einer gewissen Kompatibilitàt in der
Syntax der gàngigen Verwendung von WindowsForms
hàtte ganz ganz wesentlich begrenzen können.



Kannst du da nicht mal ein konkretes Beispiel bringen? Wenn das so einfach
ist/wàre, kann/könnte man sein eigenes Framework um beide Technologien
bauen.

Durch gleiche Namespaces mit einem anderen Vorsatz. Gleiche Klassen- und
Methodennamen für die gàngigen Properties,
Methoden und Events die wir doch in beiden Welten wohl allermeist
verwenden und brauchen.



Nenne doch mal ein Beispiel.

Viele Grüsse
Peter

Ähnliche fragen