WPF3D: XAML in C# konvertieren und vice versa

[Elemental]

Moin moin,
ich les gerade Petzold's Buch über WPF3D und find das ganze ja schon recht cool. Als alter C# Progger kann ich mich aber mit dem XAML noch nicht so ganz anfreunden.
Kann man denn den XAML Code in C# konvertieren? Gibts da evtl. Tools die das können?

mfG
Elemental

[Monger]

Da WPF ja völlig eigene Controls mit sich bringt, halte ich das für unwahrscheinlich. Das hat mit den Windows Forms nicht mehr viel gemeinsam.

Du kannst es aber wohl mischen. Sprich: die selbe Anwendung kann mal ne Windows Form und dann ein WPF Fenster aufrufen.

Wenn überhaupt, wäre es ja sowieso umgekehrt interessant. Sprich: die alten Windows Forms in XAML konvertieren. Da es aber zu vielen der alten Controls (noch?) kein Äquivalent gibt, bezweifle ich ob da ein simpler Konverter Sinn macht.

Die Idee hinter XAML ist ja gerade, dass der Designer der Oberfläche von Programmieren keine Ahnung haben muss. Der kriegt den XML Code und einen passenden Editor, und kann sich dann ganz bequem alles zusammenklicken und konfigurieren bis es passt. Das ist bei aktuellen Projekten nämlich durchaus ein Problem: aktuell muss sich der Entwickler immer noch mit dem Layout rumschlagen, obwohl er a) dafür gar nicht qualifiziert ist (Ästhetik ist nicht gerade eine Stärke von Informatikern! ;) ), und b) eigentlich auch besseres zu tun hat.

[PatkIllA]

Da WPF ja völlig eigene Controls mit sich bringt, halte ich das für unwahrscheinlich. Das hat mit den Windows Forms nicht mehr viel gemeinsam.

Du kannst es aber wohl mischen. Sprich: die selbe Anwendung kann mal ne Windows Form und dann ein WPF Fenster aufrufen.
Ich glaube er will nur zwischen Erstellung mit XAML und programmatischer Erstellung wechseln. Man kann ja fast alles auf beide Arten lösen.
Einen automatischen Weg kenne ich da aber auch nicht.

[Elemental]

Ich glaube er will nur zwischen Erstellung mit XAML und programmatischer Erstellung wechseln...

Genau!
Man kann doch alles was man im xaml schreibt auch in C# schreiben.
Schade, dass man das nicht automatisch hin- und herkonvertieren kann.

[Coda]

Ich würde aber raten sich damit anzufreunden. Es ist auf dauer extrem lästig GUIs in Code schreiben zu müssen :)

Das gilt auch für Winforms...

[Monger]

Ich hab ehrlich gesagt noch nix mit WPF gemacht, aber afaik ist ja auch der technische Hintergrund da komplett anders. WPF ist ja nicht nur der Nachfolger der Windows Forms, sondern soll auch Web und Desktop irgendwann mal zusammenführen. Sprich: ein Browser der XAML kann, kann in einer Webseite Controls darstellen die man bisher nur aus Desktop Anwendungen kannte.

Noch ist das alles Zukunftsmusik, aber wohl unter anderem deshalb ist WPF nicht abwärts kompatibel zu den alten Windows Forms.

[Gnafoo]

Ich würde auch sagen: benutze direkt XAML. Die Controls per C# zu erstellen ist zwar durchaus möglich, aber im Endeffekt einfach nur umständlich. Mit XAML geht das doch eigentlich wunderbar einfach und schnell.

[PatkIllA]

Mittels XAML kann zwar wirklich schick aussehende Controls basteln, aber für die Funktion braucht man dann doch eine Programmier- und nicht nur eine Auszeichnungssprache

[Monger]

Mittels XAML kann zwar wirklich schick aussehende Controls basteln, aber für die Funktion braucht man dann doch eine Programmier- und nicht nur eine Auszeichnungssprache

Klar. XAML alleine macht noch lange kein Programm, sondern eben nur die Oberfläche.

[Gast]

Ich hab ehrlich gesagt noch nix mit WPF gemacht, aber afaik ist ja auch der technische Hintergrund da komplett anders. WPF ist ja nicht nur der Nachfolger der Windows Forms, sondern soll auch Web und Desktop irgendwann mal zusammenführen. Sprich: ein Browser der XAML kann, kann in einer Webseite Controls darstellen die man bisher nur aus Desktop Anwendungen kannte.


Das kannst du jetzt schon machen. WPF Programme, die im Browser laufen nennen sich XBAP Anwendungen. Das ist aber nicht zu verwechseln mit Silverlight, das nur ein kleines Subset von WPF ist.

[Gauron Kampeck]

Das sehr Schöne, was mir bei meinem kurzen Ausflug in die WPF aufgefallen ist, ist die konsequente Aufteilung von Struktur (XAML) und Verhalten (C#) der Oberfläche. Mir geht diese automatische Codegenerierung des WinForm-Editors tierisch auf die Nerven und würde es vermeiden die Struktur wieder in Code gießen zu wollen.