Entschuldigung wenn ich hier jetzt einfach mal so frage aber was bitte soll daran gut sein wenn man WPF in eine veraltete Winforms klatscht?
Für mich ist das einfach nur eine schlechte Kompromisslösung für Leute die sich weiterhin WPF wiedersetzen, da sie nicht bereit sind etwas neues zu versuchen, ihren Horizont zu erweitern,... aber trotzdem die Features von WPF haben wollen.
Tatsache ist und bleibt aber nun mal einfach, dass WPF und Winforms mischen schon fast einer Todsünde gleich kommt und ich ehrlich gesagt überhaupt nicht weiß weshalb Microsoft diese Möglichkeit überhaupt zur Verfügung stellt. WPF verfolgt nun mal zu 100% andere Konzepte wie Winforms und das dann mischen.. X(

Nur weil etwas möglich ist, ist es nicht automatisch gut. Ich persönlich(und ich denke diese Meinung teilen noch viele) würde so etwas niemals jemandem empfehlen. Und dafür habe ich sehr gute Gründe.

Andy16823 schrieb:

Ich denke es giebt viele die noch mit WinForms Arbeiten und gerne ein Ribbon dabei hätten.

Dann benutzt mal wohl lieber professionellere:
officeribbon.codeplex.com/documentation
(codeproject.com/Articles/36427…a-WinForms-Application-Cs)

(mir ist klar, dass der Thread alt ist, aber für mich ist er sehr aktuell)

Erstmal vielen Dank für die Infos zum Mischen von WinForms und WPF.
Prima dass das geht!

thefiloe schrieb:

Nur weil etwas möglich ist, ist es nicht automatisch gut. Ich persönlich(und ich denke diese Meinung teilen noch viele) würde so etwas niemals jemandem empfehlen. Und dafür habe ich sehr gute Gründe.

Nun, ich höre hier nur inhaltslose Argumente, es sei eine "Todsünde" oder es gebe "gute Gründe". Worum es sich dabei genau handeln soll, höre ich nicht.

Es ist ganz klar, warum Microsoft das ausliefert, nämlich weil es gute Gründe gibt es zu tun.
Nicht jeder schreibt kleinere Projekte, die man eben mal am Wochenende neu schreiben kann.
Ich arbeite seit drei Jahren mit mehreren Entwicklern an einem Projekt, das mit Winforms begonnen wurde, da WPF-Knowhow fehlte und da viele Dinge in Winforms einfacher und besser funktionieren (zuindest als das Projekt begonnen wurde), haben wir uns für Winforms entschieden.
250.000 zeilen Code wovon sich mind. 80.000 auf Winforms Elemente beziehen.
Will man das auf einen Schlag umstellen ... wer bezahlt das? Und das nur um das Design ein wenig aufzupeppen?

Also fängt man an, das Stück für Stück zu machen und WPF zunächst da einzusetzen, wo es wichtig ist.
Ich finde es völlig legitim das zu mischen, insbesondere bei diesem Beispiel oben.

Danke nochmal und viele Grüße


ErfinderDesRades - Moderator - Notiz: Ich hab diese Nachfrage mal freigeschaltet, obwohl schon emotional angeheizt.
Ich würde eine inhaltliche Diskussion sehr begrüßen, ob und wann WinForms und Wpf zu mischen eine gute Idee ist oder nicht.
Aber ich sag gleich: bitte respektvoller Umgang, und sachlich argumentieren - "Todsünde" versus "inhaltslose Argumente" - geht beides ein bischen in eine ungute Richtung, die ich in den Tutorials nicht haben möchte.
thx

1. Ist WPF eine komplett neue Technologie, wurde auf neues ausgelegt etc. Das heißt darin hat WinForms überhaupt nichts zu suchen.
2. Gibt es in WPF allerhand Pattern etc., die für optimale und saubere Programmierung gedacht sind.
3. Wenn Du darin WinForms nutzt, dann bleibe gleich bei WinForms, wieso dann WPF? Ich glaube, Du merkst selbst, dass dies Unsinn ist.

Zu Deinen Argumenten, da muss ich Dir strikt widersprechen:
Das Problem lag dann eher an eurer Planung. Sowas sollte man vorher wissen, ob man ein gescheites Design will oder doch lieber die leichte Bedienung ne Rolle spielt.
Außerdem geht mit WPF alles viel besser, denn es ist neuer, schneller, performanter und alles.

Heißt also zu sagen, "Ich habe hier sauviele Codezeilen, wie soll man das umschreiben, da muss man das so machen" kann man so nicht direkt sehen. Das Problem ist dann eher, dass Ihr bereits bei der Projektplanung dies wohl eher weniger beachtet habt und eventuell etwas zu schlecht durchdacht. (Nicht als Angriff sehen)
Also vorher entscheiden, was man für Prioritäten hat und dann konkret und detailliert alles planen. Das ist sehr wichtig.

Aber dann einfach hergehen und mischen, das ist Unsinn, siehe Argumente oben.
Mal davon abgesehen, dass es hier um ein Ribbon-Control geht, was übrigens genauso gut in Windows Forms möglich ist (siehe Gather's Links). Das zu nutzen wäre dann wenigstens ne gute Lösung und anbei kriegt man noch nen relativ gutes Design damit hin.
Das heißt, hier gäbe es erst recht keinen Grund das zu machen.

Es gibt nämlich auch für Windows Forms genug Möglichkeiten ein modernes Design zu schaffen, da reicht meist schon ein wenig Aerostyle mit modernen Farben und Schriftarten und fertig.
Heißt: Du kannst Windows Forms nutzen und dafür auch erstellte Controls etc. einbinden und auf die GUI ziehen und verwenden und Du kannst WPF nutzen, alles schön per XAML erstellen und dafür geeignetes Zeugs verwenden. Aber nicht beides.
WinForms ist WinForms und WPF ist WPF. Beides hat speziell angefertigte Sachen, die man jeweils dafür nutzen kann, aber beides mischen ist auf Grund der Designunterschiede, der verfolgten Ideen und Verhaltensdifferenzen, sowie auch der Art des Codens, keine gute Idee.

Grüße

Ich halte auch nicht viel von mischen.
Der minder wichtige Punkt ist die Bläh-Ware, die entsteht, wenn man die äusserst umfangreichen Wpf-Bibliotheken einbindet.
Aber wesentlicher ist, dass Wpf viele geniale Konzepte beinhaltet, und durchgehend darauf aufbaut, die aber nicht kompatibel mit WinForms sind: Zuallererst der MVVM-Pattern, aber auch die Styles und Templates, oder die Geschichte mittm DataContext.
Das wird alles mit ziemlicher Sicherheit nicht oder grottenfalsch angewendet werden, wenn man versucht, ein großes WinForms-Teil stückchenweise umzubauen statt eines grundlegenden ReWrites.
Und imo das problematischste daran: die Firma hat dadurch ihr Personal verdorben.
Die WinForms-Entwickler, die so stückchenweise quasi eine "Wpf-Mißgeburt" geschaffen haben, denken irgendwann natürlich, sie verstünden was von Wpf - und liegen völlig falsch!
Und können auch in Zukunft nichts als Grotten-Code produzieren - weil habens halt so gelernt, und gibt in der ganzen Firma auch kein korrigierendes Feedback.

Also das mit den 250000 Zeilen Code ist echt blöd, da mag ein Rewrite finanziell schlicht nicht machbar sein. Vlt. könnte man einen Wpf-Profi ins Boot zu holen - quasi als Coach - nur gibts da nicht wenige "Profis" äusserst fragwürdiger Qualität - wie wolltet ihr das einschätzen, was einer kann?

Übrigens son Ribbon-Control in eine WinForms-Anwendung einzubetten, finde ich recht unproblematisch: Da hat man zwar eine Riesen-Bibliothek zuzuladen, aber es wird kein Stil verhunzt: Es bleibt halt WinForms-Stil, und ist ja auch ok.