WPF, Visuelle Vererbung

Question

Hallo Forum,

Kurze Vorgeschichte:

In WinForms gab es die visuelle und die Code-Vererbung, die ich für unsere Visualisierung und speziell

für Dialog-Formulare genutzt habe.

Ein Basisdialog, der so eine Art Rahmen-Dialog ist und immer gewisse Standard-Element hatte:

Titelleiste, Standard-Symbole, Ok- und Close Button (und noch einige mehr die hier jetzt aber keine Rolle spielen).

Dazu konnte man im zugehörigen Code-Behind in den Ableitungen auch (virtuelle) Methoden vererben und überschreiben.

Wir nennen diese Dialog-Konzept die "Komponenten-Dialoge" die sehr wichtig für uns sind.

Nun gibt es ja in WPF diese Art der visuellen Vererbung leider nicht mehr.

Wie könnte man das in WPF nun nachbauen (Styles, ControlTemplates, etc.)?

Vielen Dank für Antworten schon mal.

Gruß, myamadeus.

Answer 1

Hallo,

das mit dem "Vererben" funktioniert so nicht mehr, weil WPF keinen Quellcode erzeugt, wie es Windows Forms tat. Vielmehr wird das XAML in kompilierter Form als Ressource abgelegt...

Was man als Alternative machen kann, hängt davon ab, was man alles erreichen will. Der angesprochene Basis Dialog wäre bei einigen Schaltflächen ist IMHO die Mühe nicht wert. Das Aussehen kann man dabei über Stile ebenso festlegen - siehe z. B. CodeProject WPF: Customize your Application with Styles and Control Templates (Part 1 of 2). Oder ControlTemplates, wenn die einzelnen Schaltflächen stärker variieren (was sie laut Windows Style Guide aber eher nicht tun sollten ;)

Weitere Varianten zeigt auf Übersicht über das Erstellen von Steuerelementen

Auf Code Behind sollte man dabei weitgehend verzichten. Verwendet man MVVM mit ViewModels so kann darüber leicht eine weitere Anpassung erfolgen; und ViewModels können ggg. vererbt werden.>

Vergleichbares gilt für andere Steuerelemente.

Gruß Elmar

Answer 2

Hallo Elmar,

danke für die Antwort.

Ja gut, da muss ich mich wohl durch Styles, Templates und MVVM's durchkämpfen.

Ich meine WPF bietet ja verdammt viel Möglichkeiten in Sachen Vektor-Graphik, Skalierung, 3D, etc.

Ich möchte es auch nicht schlecht reden, aber trotzdem, mit RAD hat das nichts mehr zu tun.

Unser flexibles Konzept der component dialogs nachzubauen wird hier deutlich länger dauern als

in WinForms, soviel ist sicher.

Gruß, myamadeus.

Answer 3

Hallo Amadeus,

dafür kann man Dinge machen, da träumt Windows Forms nicht mal von, schon weil es im Käfig Windows API gefangen ist ;)

Nur als Beispiel https://github.com/thinkpixellab/bot (die Silverlight/Phone Projekte kann man raus nehmen, wenn sie stören)

oder etwas DirectX: Windows Presentation Foundation Pixel Shader Effects Library

Gruß Elmar

Answer 4

Hallo Elmar,

noch mal danke für die Links.

Na da hab ich ja genug stuff zum lernen :-)

Gruß.

Answer 5

Hallo myamadeus,

noch ein Rat von mir. Vielleicht solltest du auch moderne Aspekte der Softwareentwicklung betrachten, anstelle des reinen "Kopieren" deiner WinForms-Anwendung auf WPF.

Dein Beispiel von Codebehind in einem Formular ist zum Beispiel ein Aspekt, der geändert werden sollte.

WPF bietet beispielsweise die Möglichkeit, die Programmlogik komplett von der GUI zu trennen, das Pattern nennt sich MVVM. Beschäftige dich mal damit, es ist äußerst spannend. Es ist möglich, eine WPF-Anwendung komplett ohne Codebehind zu entwickeln. Die GUI-Elemente (auch Views genannt) dienen dabei nur der Darstellung. Sie können beliebig ausgetauscht werden. Du kannst beispielsweise für verschiedene Kunden deiner Anwendung über eine PlugIn-Architektur (MEF) verschiedene Views implementieren. Du kannst sogar mit wenig Aufwand dein Programm in eine Web-Anwendung portieren, die Logik/Daten befinden sich in eigenen Klassen (ViewModels bzw. Controller) und du musst quasi nur die Views (ASP.NET) neu gestalten.

Moderne Softwarearchitekturen zeichnen sich dadurch aus, dass sie in Bezug auf Wartung, Austauschbarkeit und Testbarkeit langfristig effizienter sind.

Schaue dir Microsoft Prism oder MvvmLight von GalaSoft an. Das sind 2 gängige MVVM-Frameworks.

Grüße

Sven

Answer 6

Hallo Sven,

danke für Deine Antwort.

Ja, ganz so einfach ist es leider nicht.

Ich bin schon ein paar Jahre im Geschäft (> 20 Jahre, Borland-C++, Visual Basic, VisualC++-MFC, C# mit .NET)

wollte ich mal bemerken. Ich habe schon viele IDEs, Visu-Systeme, etc. kennen- und ertragen gelernt :-).

Jedes hat von sich behauptet, das Beste zu sein.

Außerdem habe ich keine "Anwendung", sondern eine fette HMI/SCADA-Visu die, mit der PLC kommuniziert

und nicht so einfach mal irgendwohin portiert werden kann.

Es ist natürlich auch wie immer eine Zeit- und Kostenfrage, der Druck des Managements ist schon spürbar.

Deshalb wäre es als erste Maßnahme nicht schlecht gewesen, unser Dialog-Komponenten-System adäquat

übernehmen zu können.

Ich werde nicht drum rumkommen und mich mit den Programmier-Paradigmen der WPF auseinandersetzen müssen, wenn wir unser System vernünftig nach WPF bringen wollen.

Gruß.

Answer 7

Hi myamadeus,

Es ist nie zu spät, etwas neues zu lernen. ;-)

Derartige Projekte habe ich auch schon realisiert. Beispielsweise habe ich mal eine Visualisierung für einen Automobilspeicher von Visual Basic 6 auf .NET (C#) portiert. Da habe ich auch WPF und MVVM eingesetzt.

Dein Dialogkomponenten-System lässt sich mit WPF/MVVM sehr gut umsetzen, in dem du die ViewModels zu den entsprechenden Views bindest.

Beispielsweise kannst du deinen Basisdialog in XAML erstellen und fügst für den dynamischen Inhaltsbereich  einfach einen ContentPresenter ein. Den Inhalt des ContentPresenter kannst du dynamisch aus dem ViewModel per Binding setzen. Du musst dir dazu einige Beispiele anschauen, um es besser zu verstehen.

Die Lernkurve ist anfangs sehr steil, aber du kommst schnell dahinter.

Klar, man muss auch immer den Kosten/Nutzenfaktor berücksichtigen.

Viel Erfolg!

Grüße

Sven

Edit: Hier noch ein nützlicher Link zu einigen Lernressourcen: Good examples of MVVM template