MVVM-Parameter an VM bevor View lädt

  • WPF

Es gibt 12 Antworten in diesem Thema. Der letzte Beitrag () ist von Eggord.

    MVVM-Parameter an VM bevor View lädt

    Hey.

    ich habe ein UserControl, und ein dazugehöriges VM. Nun wird dieses UserControl vom MainWindow(oder irgendeinem anderen Window) aufgerufen. Das VM wird in dem UserCOntrol im XAMl in die resourcen eingebunden. Das funktioniert auch super. Allerdings muss ich vom Mainwindow einige parameter an das VM übergeben und zwar eigetlich bevor oder während das UserControl läd.Ich hae nun schon eine Weile geschaut bei MVVM Beispielen aber nichts richtiges dazu gefunden. Ich hoffe ihr könnt mir mal wieder weiterhelfen ;)

    Danke!
    Entschuldigt alte Angewohnheit. Bin neu in WPF.
    Das Usercontrol wird im Mainwindow in Xaml eingebaut. Aber zudem werden über Buttons im MainWindow neue Windows erzeugt in welche die ucl eingebettet werden. Ich muss aber beim Erzeugen der anderen Windows Parameter an das VM des ucl übergeben. Ich hoffe ich habe es besser erklären können

    Eggord schrieb:

    Aber zudem werden über Buttons im MainWindow neue Windows erzeugt
    bei mir werden, wenn ich neue Windows erzeuge, diese nicht im Window erzeugt, sondern im Viewmodel. Und da kann ich dann auch Parameter angeben.
    guggemol die Solution von Binding-Picking im Xaml-Editor
    mir ist nicht ganz klar was du meinst. Bei mir werden die Windows im VM vom Mainwindow erzeugt. Allerdings hat das neue Window mit dem ucl ein anderes VM. Das VM des ucl muss den parameter aber schon im Constructor kennen.
    Ich glaube das beste ist ich versuche es nochmal von vorne.Irgendwie habe ich immer probleme verständlich zu schreiben was ich möchte-sry

    Ich habe ein Mainwindow in dieses werden mehrere ucl eingebetet. Dann sollen aus dem Mainwindow(per Button) aus ein neues Window(#) erzeugt werden, in welchem auch wieder ein ucl eingebetet ist.(vll wird das ucl auch direkt erzeugt, ka ob das überhaupt geht) In den Xaml code der ucl ist das VM eingebettet.(Wenn ich meherere ucl's habe und allen das VM eingebetet ist, sind das dann auch unterschiedliche Instanzen?). Jetzt muss ich nun einen Parameter bei erzeugen der ucl's von # dem VM des ucl übergeben.

    Ich hoffe ich habe es geschafft es einigermaßen verständlich zu schildern. Danke!
    ja, wird langsam besser. Nurnoch:

    Eggord schrieb:

    Dann sollen aus dem Mainwindow(per Button) aus ein neues Window(#) erzeugt werden
    Die Frage ist, wo der Code steht, der vom Button-Command aufgerufen wird: Im CodeBehind oder im Viewmodel?

    Codebehind wäre schlecht, denn das ist zu eng ans Xaml gekoppelt.
    Das Command muß im Viewmodel verarbeitet werden, wo auch die annere Anwendungslogik implementiert ist.

    Ich hoffe, du verstehst wassich meine.
    Also bis jetzt habe ich noch kein Viewmodel für das MainWindow sondern nur für die ucl im MW. Dazu zu sagen ist, das jedes ucl ein eigenes VM hat.
    Aber dann werde ich für das MW auch ein VM erstellen und von daraus den Button-Command aufrufen. Aber wie übergebe ich dann dem VM des neu erstellten ucl einen Parameter. Ich müsste das dann ja über das ucl also View machen, da das VM . Dann gebe ich den Parameter an das VM welches den Parameter wieder an eine Eigenschaft des Views bindet.

    Eggord schrieb:

    Aber dann werde ich für das MW auch ein VM erstellen und von daraus den Button-Command aufrufen.
    ähm - annersrum: Der Button im MW ruft den Command im VM auf.

    Zum Problem mitte mehrfachen VMs: Es darf nur eines geben (Redundanz-Verbot). Und das kannman hinkriegen, indem man es nicht in Windows oder ucls anlegt, sondern im Application.Xaml.
    Die DataContexte aller Xaml-Dateien können an dieses eine VM gebunden werden.

    Aber man muß halt gucken: Manchmal ist sinnvoll, dass untergeordnete VMs in Listen innerhalb des MainViewmodels gehalten werden, sodass Ucls daran binden können.

    Aber zB bei DialogFenstern scheint mir sinnvoll, es hat sein eigenes Viewmodel im Xaml instanziert, und übers Public Methoden im Codebehind kann man dieses VM manipulieren.

    So ists jdfs. im gegebenen Tut gemacht.
    ahhh ok...ein VM für alles. Dann muss ich mal mein Konzept überdenken. Sub VM höre ich jetzt auch zum erten mal. Aber mal schauen was ich so finden kann. Bei den ganzen ucl könnte das ein gutes Konzept sein. DANKE!

    Ab wieso DialogFenstern eigene VM haben sollten verstehe ich noch nicht. Was unterscheidet die von meinen ucl, die ich in ein extra Fenster binden möchte?

    ErfinderDesRades schrieb:

    und übers Public Methoden im Codebehind kann man dieses VM manipulieren.
    Ist das dann noch MVVM? Man ändert im View etwas, welches das weiter ans VM gibt und dann wieder zurück im View was ändert.
    ich weiß ja nix von deine Fenster, ob das Dialoge sind, im Sinne unabhängiger Einheiten, die man instanziert, anzeigt und wieder schließt.

    Dass man das VM eines Dialogs über Public Methoden im Codebehind steuert - nö, dassis glaub kein MVVM.
    Ich weiß nur keine annere Möglichkeit.
    Ich finde das halt logisch, dass ein FolderBrowser-Dialog eine SelectedPath-Property hat.

    Dassis halt mein Verständnis von Dialogen: ein Fenster mit einer DAten-Property, und die kann man vorbelegen, der Dialog ändert sie dann, und wenner mit DialogResult.Ok schlißt, wird die DatenProperty in die HauptAnwendung übernommen.
    ja wahrscheinlich sind meine Fenster eher keine Dalog-Fenster. naja egal...muss man jetzt nicht klären...gerade nicht an einem Sonntag.

    Übrigens vielen Danke dass du mir an geholfen hast!! :thumbsup:

    Falls ich weitere Fragen habe melde ich mich ;)