none
Wpf-Window aus einem Projekt in der Projektmappe in ein anderes Projekt der Projektmappe übergeben RRS feed

  • Allgemeine Diskussion

  • In letzter Zeit werden meine Projekte größer und ich verwende oft 2 oder 3 Projekte in einer Projektmappe. Die Projekte tauschen Daten untereinander aus (jedes Projekt hat eine bestimmte Zuständigkeit, z.B. Pdf-Zeichnungen anzuzeigen und die Berechtigungen zu prüfen).

    Nun habe ich ein Problem in einer Projektmappe. Ich habe zwei Projekte drin, A und B. A organisiert und verwaltet Korrekturen uas Maschinenprogrammen. B visualisiert Daten (Bediener kann dann noch etwas eingeben wenn etwas fehlt, oder korrigieren) und speichert dann diese ab, wenn dies erforderlich ist. Der Zustand ist so, dass A etwas von B verwendet, und bei der Speicherung und Visualisierung B das MainWindow von A braucht.

    Somit habe ich eine Ringabhängigkeit. Hatte das zuerst so gemacht, das ich aus B eine DLL erzeugt hatte und diese dann als Verweis bei A eingebunden habe und dann das Projekt erstellt.Allerdings wollte ich da von A noch nicht das MainWindow an B übergeben.

    Nun möchte ich aber noch von A an B das MainWindow übergeben. Dann fällt das Kartenhaus zusammen, weil ich nun bei der DLL-Erstellung auch das Projekt A brauche. Wie mache ich das in so einem Fall, das ich das Window übergeben kann (wegen den Abhängigkeiten??)

    Kann ich das Window irgendwo global erstellen (weiteres Projekt), und beide Projekte könne davon eine Instanz verwenden, oder wie mache ich da ein sauberes Design?


    oema von MSDN


    • Bearbeitet oema Dienstag, 6. August 2013 06:09 Schreibfehler
    • Typ geändert Ciprian Bogdan Montag, 24. März 2014 12:44 keine Rückmeldung des Fragestellenden
    Dienstag, 6. August 2013 06:09

Alle Antworten

  • Hi oema,

    grundlegend verwendet man eine mehrschichtige Architektur, hier mal ein Link (den hab ich mir aber jetzt nicht im Detail durchgelesen).

    Prism kann man sich auch mal Anschauen.  Dort hat man einen Ausführlichen Ansatz.

    Eine direkte Lösung für dich wäre gemeinsam genutzte Klassen von A und B in C auslagern. Dann kennen sich A und B nicht, sondern sie kennen nur C.

    Mann könnte auch in B ein Inteface bereitstellen, welche vom MainWindow in A implementiert wird. Dann kann ich B aus A Instanzieren und das MainWindow an einer Schnittstelle mit dem Inteface übergeben.

    B könnte auch ein Event haben, welches A dann abfängt um dann das Fenster anzuzeigen.

    MFG

    Björn

    Dienstag, 6. August 2013 07:05
  • Hallo, danke für die Infos. Das Auslagern in eine ClassLibrary (C) habe ich schon gemacht. Leider habe ich aber noch die WPF-WindowsForm (B), die ich aus (A) heraus öffnen lassen möchte, und dabei die WPF-WindowsForm (A) mitübergeben, damit ich dann nach erfolgreichen Methodenabarbeitungen in (B) bestimmte Controls in (A) zurückgesetzt oder anders farblich markiert dargestellt werden. Das riecht dann wohl nach "MVVM", oder? Oder gibt es da noch  einen Trick, der aber nicht so sauber und gut ist (PInvoke oder so)?

    Also an der Übergabe des Windows scheiterts noch.


    oema von MSDN

    Dienstag, 6. August 2013 09:08
  • Hi,

    MVVM ist natürlich ein gutes Entwurfsmuster. Muss aber nicht unbedingt eingesetzt werden. 

    Grundlegend sollte man aber bei der Entwicklung schon ein wenig Zeit in den Entwurf investieren, besonders wenn die Anwendung größer wird. Das führt meist zu besserer Wartbarkeit, weniger Fehler, im Endeffekt also zu geringeren Kosten und größerer Kundenzufriedenheit ;) .

    Wenn es nur darum geht, die Controls zurück zu setzen und du jetzt keine größeren Änderungen machen willst. Würde ich wohl in B ein Event bereitstellen was A abonniert, über die EventArgs kannst du bei bedarf noch weitere Informationen austauschen b.z.w über Propertys von B. Das sollte ohne Probleme klappen, wenn B nicht in einen eigenen Thread läuft.

    Da ich dein Programm nicht kenne, ist es natürlich schwer eine genaue Aussage zu treffen. Falls du planst dein Programm in Zukunft zu erweitern und/oder es für irgendwelche Kunden gedacht. Lohnt sich sicher an diesen Punkt, die Zeit aufzuwenden um einen sauberen Entwurf zu machen.

    MFG

    Björn

       

     

    Dienstag, 6. August 2013 10:00
  • Hallo Björn, werde mir das mal genauer überdenken. Im Moment ist das so, das ich zwei Fenster habe. Fenster A-Steuerungstool und Fenster B-Autoarchivierung (visualisiert die Daten zu einem gewissen Zeitpunkt damit User Daten vervollständigen kann wenn etwas fehlt).

    B-Auoarchivierung muss dann noch in A irgendwelche Controls wieder eingrauen und färben, damit der User weiss wie der aktuelle Stand ist.Das wäre dann so, dass ich noch die Klasse C brauche, die A und B kennt, A und B kennen sich aber nicht. Datenaustausch soll dann über Events laufen, was ich aber noch nie gemacht habe. Das heißt, in C habe ich Methoden und Events, die A und B verwenden um Daten und Controls zu aktualisieren? Sehe ich das so richtig?


    oema von MSDN

    Freitag, 9. August 2013 07:40
  • Ja, wenn du auf Änderungen der Eigenschaften von C reagieren willst, könnte C das PropertyChanged Event Implementieren. Events zu Implementieren ist wirklich nicht schwer und gehört so zu den Grundlagen welche man können sollte.
    Freitag, 9. August 2013 08:35
  • Hi,
    ich würde das nach dem Prinzip "Jeder holt sich das, was er benötigt" machen. Das entspricht dem MVVM Entwurfsmuster.

    Für Dein Beispiel gäbe es 3 Projekte:
    - WPF Anwendung mit Fenster A-Steuerungstool
    - WPF Anwendung mit Fenster B-Autoarchivierung
    - Klassenbibliothek C

    Wenn die beiden WPF Projekte unabhängig nebeneinander gestartet werden, musst Du eine interprocess-kommunikation organisieren. Wenn jedoch eine WPF Anwendung gestartet wird und dann aus der anderen WPF Anwendung die benötigten Klassen instanziiert und ausgeführt werden, kann die erste Anwendung Instanzen der Klassenbibliotheken den weiteren Methoden bereitstellen. In den Oberflächen können dann die bereitgestellten Instanzen für Datenbindungen genutzt werden.

    Wenn beispielsweise Fenster B-Autoarchivierung einen neuen Zustand bewirkt, werden in der Instanz C Eigenschaftswerte geändert, z.B. eine Eigenschaft für Ausgrauen. Die Änderung des Eigenschaftswertes ruft NotifyPropertyChanged auf. Im Fenster A-Steuerungstool ist beispielsweise die Hintergrundfarbe eines Steuerelementes an diese Eigenschaft (der gleichen Instanz C) gebunden, ggf. über einen Converter. Bei dieser Verfahrensweise ist es überhaupt nicht erforderlich, dass Fenster A-Steuerungstool das Fenster B-Autoarchivierung kennt und umgekehrt. Es müssen lediglich beide C kennen und die gewünschten Eigenschaften binden. Wer dann einen Eigenschaftswert ändert ist ohne Bedeutung.

    --
    Peter

    Freitag, 9. August 2013 09:00
  • Hallo oema,

    bist Du da weitergekommen? - Wenn dir die Beiträge von Björn und Peter geholfen haben, markiere sie bitte als Antwort und/oder als hilfreich. Danke.

    Gruß
    Marcel

    Samstag, 31. August 2013 07:50
    Moderator
  • Nein.Muss mir das mit den Events ansehen wie ich das genau anmelde, sowie ie Callbacks.

    oema von MSDN

    Donnerstag, 5. September 2013 16:24
  • Hallo oema,

    eventuell ist für dich an dieser Stelle das MEF interessant um das Framework die Arbeit für dich machen zu lassen. Bei mir ist es in einem Projekt ähnlich. Habe die WPF Windows in einem Projekt und die Controller in einem anderen. Einzige Verbindung ist ein Interface, das die WPF Windows implementieren und sich veröffentlichen.

    Als Denkanstoß hab ich damals das WPF Application Framework verwendet.

    MEF: http://msdn.microsoft.com/de-de/library/vstudio/dd460648.aspx

    WAF: http://waf.codeplex.com/

    Mfg

    Stefan

    Dienstag, 1. Oktober 2013 06:23
  • *****************************************************************************************************

    Dieser Thread wurde mangels weiterer Beteiligung des Fragestellenden ohne bestätigte Lösung abgeschlossen.

    Neue Rückfragen oder Ergänzungen zu diesem Thread bleiben weiterhin möglich.

    *****************************************************************************************************

    Ciprian Bogdan, MICROSOFT   Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-PrinzipEntwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.





    Montag, 24. März 2014 12:44