Praxisumfrage: Panel/Frame-Mix mit Forms und WPF



  • Hallo Communitonen!

    Ich muss leider eine alte Entwicklung von mir aufbohren. Wurde damals mit .Net 2.1 mit Forms erstellt.
    Nun sollen neue Entwicklungen erstellt werden und gemäß den modernen Frameworks 3.0+ ein "Panel", das über Split erstellt wurde abgelöst werden, um grafische Illustrationen mit WPF (XAML) einzufügen, die sich über die ehemaligen SplitContainer hinweg erstrecken und bis in das Panel des Forms reichen.
    Über Split oder Frame, das ist auch hier die Frage ... 😕

    Jetzt habe ich zwei verschiedene Grundtechniken - Forms und WPF - und weiß nicht ob die miteinander kompatibel zu bekommen sind für eine solche Entwicklung und was wie vorzuziehen wäre.

    Hat damit schon jemand praktische Erfahrung und kann mir diese berichten?

    EDIT:
    http://msdn.microsoft.com/de-de/library/system.windows.forms.integration.elementhost.aspx
    Hat das hier schon jemand angewandt?

    Danke im Voraus. 🙂



  • Siehe evtl. auch das Gegenstück für Windows-Forms in WPF:

    http://msdn.microsoft.com/de-de/library/system.windows.forms.integration.windowsformshost.aspx

    Erfahrungen: bisher keine



  • Super! - Danke. 🙂

    Hat wirklich keiner Erfahrung damit?

    Mit der Intentions im Haupt-Frame/-Panel eine bereichsgreifende Grafik zu erstellen.

    Entweder:
    a) Hauptframe mit zwei Frames - wobei als einer der Frames einen Panel mit WinForms.
    😎 Hauptpanel mit zwei Panels - wobei als einer der Panel mit Frames mit WPF.



  • Ich habe mal vor langer Zeit das Gegenstück genutzt um DataGrids von Windows Forms in einer WPF App nutzen zu können bevor es diese Komponente bei WPF überhaupt gab (das war in 3.5 oder sogar noch vorher). Im Prinzip lief das alles ohne Probleme, aber es treffen halt zwei komplett verschiedene Welten aufeinander. Weiterhin hatte ich immer ein wenig den Eindruck dass die Performance leidet, was nicht weiter überrascht.

    Was ich nicht ganz verstanden habe ist was du eigentlich bauen willst. Ein Control einbetten geht ja, aber dieses "hinweg Erstrecken" macht mir ein wenig Sorgen. Einen SplitContainer realisiert man in WPF zumeist mit Grid oder evtl. DockPanel. Den Zusammenhang mit Frames sehe ich hier nicht recht.



  • @Prof84
    Wenn du Forms Controls innerhalb einer WPF GUI hosten willst, dann können die beiden Welten grafisch nicht überlappen.
    Popup-Menus und Dropdowns von Comboboxen o.Ä. gehen (weil die bei WPF eigene Fenster bekommen), aber "normale" Controls oder Visuals gehen nicht.

    Ich vermute dass es genau so sein wird wenn man WPF Controls innerhalb einer Forms GUI hosten will.

    ps:

    Prof84 schrieb:

    Mit der Intentions im Haupt-Frame/-Panel eine bereichsgreifende Grafik zu erstellen.

    Wenn du keine so komischen Wörter wie "bereichsgreifend" verwenden würdest, dann würdest du vermutlich besser verstanden werden.

    Tip: komische und unübliche Wörter zu verwenden, die keiner richtig zuordnen kann, lässt dich nicht schlau aussehen (ganz im Gegenteil, es führt zu der Vermutung dass du keinen Plan hast wovon du redest -- zumindest bei mir). Du kannst also einfach damit aufhören ohne einen Image-Verlust zu erleiden.



  • Hallo!

    Also ich habe einen Feldversuch gestartet und kam zu folgenden Ergebnis:

    WPF (XAML) ist vorzuziehen, MS hat die Weiterentwicklung von WinForms zu Gunsten XAML bereits eingestellt.

    Also ich habe einen komplizierten Layout-Container aus Grid, Dock-Panel, Stack-Panel, Panel-Splitter, Grid-Splitter und einem Frame im Hauptfenster mit XAML erstellt und quer über das Fenster mal eine Canvas mit einer Linie gezogen. Grafisch scheint hier Keiner Keinen zu stören. Auch der VS 2012-Generator für Xaml stört sich nicht an Formentwicklungen.

    WindowsFormsHost-Klasse implementiert und im Grid einfach ein Formelelement zu setzen funzt easy. Auch ein triviales using mit der Form-Klasse im Code stört WPF nicht.
    Edit: Mit Ausnahme sich gelegentlich überlagenden Namensräumen.

    Mein altes Form-Layout habe ich mit einer trivialen Page in einem Frame gesetzt und funzt ebenfalls prima. Ja, der Datenaustausch muss neu gecodet werden, weil der Sichtbarkeitbereich durch das Frame beschnitten wird.

    XAML ist viel prozessdualer als Form-Code (OO). Deshalb muss man mehr die Reihenfolge beachten. Auch kann man die Container-Layout Elemente nicht wahlfrei ineinander stecken. Muss man ein wenig fummeln.

    Apropros Fummeln - Ein banales Problem bekomme ich im Moment nicht gelöst:
    Ich habe in einer Zelle eines Grids das Frame eingebedded. Aber wenn ich die Zelle mit der Mouse verkleinere, überlagert es immer den Frame. Eine Koppelung mit dem Grid<->Frame<->Page gelingt mir irgendwie nicht.

    Hat einer Ideen dazu?
    Edit: Hat sich erledigt. Aus unerklärlichen Gründen wird bei einer RichTextbox Width="auto" nicht ausgeführt, Height="auto" aber schon - It's not a bug, it's a feature. 😉
    http://connect.microsoft.com/VisualStudio/feedback/details/354442/wpf-richtextbox-wrapping-fails-in-listboxA - Loser. :p


Anmelden zum Antworten