DataBinding mit einem TabControl auf einem untergeordnetem Fenster

  • WPF

Es gibt 47 Antworten in diesem Thema. Der letzte Beitrag () ist von Nofear23m.

    Nofear23m schrieb:

    Es geht NICHT darum welche Lösung besser ist, es geht darum welche korrekt ist.
    Wie du wolle. Ich finde eine bessere Lösung besser, auch wenn es Definitionen gibt, nach denen sie nicht "korrekt" ist.

    Aber nochmal ganz unabhängig vonne Rechthabereri und sonstigem Hickhack: Guck nochmal post#39, snippet#1, zeile#9.
    Das muss wirklich ein Versehen sein von dir, wenn du da im RemoveHandler-Abschnitt AddHandler aufrufst statt RemoveHandler.
    Hallo

    ​Danke für den Hinweis.
    ​Habe ich jetzt getestet und ausgebessert. Ich muss dir sagen das ich keine Ahnung habe warum ich das drinnen hatte und weis auch nicht wie das zu stande kommt. Voll logisch das das Quatsch ist. Was nur komisch ist. Ich habe es nie bemerk und es funzt alles. Auch MemoryLeaks konnte ich keine verzeichnen. Danke dafür!!

    ​Aber genau deshalb ist es ja gut wenn man hier und da Code austauscht, ich persönlich finde es Klasse zu sehen wie andere ein Problem lösen.
    ​Außerdem würde mich auch deine RelayCommand Klasse interessieren. Ich habe mich mit dieser Klasse nicht lange beschäftigt, muss ich zugeben.

    ​Wenn alles Sachlich bleibt finde ich solche Diskussionen auch super genial. Ich habe so gut wie alles über Foren gelernt und mir zusammen getragen.
    ​Leider ist es oft schade das man dann manchmal wenn man seinen Code zeigt oder Online stellt einfach unsachlich "ausgelacht" oder in eine Ecke gestellt wird.
    ​Nur weil jemand weiter ist muss er andere deshalb nicht auslachen, er hat es auch mal gelernt und soll sich doch bitte mal daran zurück erinnern. Aller Anfang ist schwer, und wenn das jemand nicht mehr weis sollte man dessen Gedächtnis wieder auf die Sprünge helfen.

    ​In diesem Sinne, Danke für den Hinweis und auf viele fruchtende Stunden in diesem Forum.
    Schöne Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    wie sowas entsteht ist mir recht plausibel: AddHandler/RemoveHandler sind ein logisches Pärchen, und man (ich zumindest) programmiere einen Pair-Teil meist mit Copy&Paste, und stell den dann um. Und dieses Nachbessern ist ja schnell mal vergessen.
    Warum da nix passiert reime ich mir so zusammen, dass es eiglich kaum vorkommt, dass ein RelayCommand-Handler jemals deregistriert wird.
    Bzw deregistriert wird, wenn das Window abgeräumt wird, und dann richtet das auch nichts mehr an, weil das Control kann ja nichtmehr geklickst werden.
    Es dürfte allerdings ein klein Memory-Leak geben, weil das Control kann nicht gegarbageCollected werden, denn der CommandManager behält eine Referenz auf dieses Control.

    Mein RelayCommand ist glaub in meim Tut mit drinne: Grundlagen - MVVM-Anwendungs-Struktur
    Tatsächlich sinds 2 RelayCommands: eines mit und eines ohne Parameter.
    Und eine Besonderheit ist auch, dass es nicht nur (gezwungenermassen) ein CanExecuteChanged-Event hat, sondern es hat auch eine dementsprechende Property!
    Es ist ja ein Pattern, dass ein Event XYChanged oft zusammengehört mit einer Property XY, die gechanged wird (zb Visible/VisibleChanged, Enabled/EnabledChanged, DataContext/DataContextChanged,...).
    Wie gesagt: der Command-Pattern ist sehr eigenartig, weil das XY heisst da ja CanExecute - ist aber keine Property, sondern eine Function! 8|
    Kann also nicht gesetzt werden, wie normale Properties.
    Daher musste ich bei mir die Property Enabled nennen, und die korrespondiert nu mittm CanExecuteChanged-Event.
    Wird aber im Tut-Code garnet genutzt - ist aber dennoch nützlich - also ich kann im Viewmodel Commands dis/en-ablen, wenn ich will.
    Aber das sind so Feinheiten, warum ich keines der vielen MVVM-Frameworks verwende, sondern lieber mein selbstgebastelten Mist.

    Hmm - hier nu mein RelayCommand zu diskutieren ist aber ziemlich OffTopic - nur wo wäre es OnTopic?
    Hallo

    AddHandler/RemoveHandler sind ein logisches Pärchen, und man (ich zumindest) programmiere einen Pair-Teil meist mit Copy&Paste, und stell den dann um

    Gut möglich mache ich aber fast nie, genau aus solchen Gründen. Aber vielleicht war ich mal nicht konsequent. Danke nochmals für den Hinweis. ;)

    Mein RelayCommand ist glaub in meim Tut mit drinne

    Muss ich mir ansehen, Danke!

    Aber das sind so Feinheiten, warum ich keines der vielen MVVM-Frameworks verwende, sondern lieber mein selbstgebastelten Mist.

    Genau wie ich, es gibt viele MVVM Frameworks, aber ich will meinen Code selbst in der Hand haben. Wenn mal was nicht so macht wie ich will hab ich es in der Hand.

    nur wo wäre es OnTopic?

    Naja, ich weis nicht. Da leider um die WPF hier sooo wenig los ist.... wie wäre es wenn man ein Tutorial macht. WPF von ganz von Anfang bis hin zum MVVM und einer UWP App.
    Aber hier sollten wir nix mehr schreiben, lieber per PM und dann mal sehen.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Schön dass sich alle wieder lieb haben :)

    Ich habe das Schließen über Buttons oder vom Code aus nun Events gelöst, welche im Window_Loaded bzw. im Window_Closed Event abonniert bzw. deabonniert werden. Funktioniert gut.

    VB.NET-Quellcode

    1. Public Event CloseWindow()
    2. Public Event WindowClosed(sender As WindowBaseVM)
    3. Private _isOpen As Boolean = False
    4. Public Property IsOpen As Boolean
    5. Get
    6. Return _isOpen
    7. End Get
    8. Set(value As Boolean)
    9. _isOpen = value
    10. If Not value Then RaiseEvent WindowClosed(Me)
    11. End Set
    12. End Property
    13. Public MustOverride ReadOnly Property DataContextVM As ViewModelBase
    14. Public Sub RequestWindowCLosing()
    15. RaiseEvent CloseWindow()
    16. End Sub



    Zusätzlich musste ich den ganzen Fensterkram mal gesammelt in ein eigenes Viewmodel ausgelagern, da mein MainVM mittlerweile zu einem unübersichtlichen 700-Zeilen Monster angewachsen war.....

    Eine Frage habe ich noch:
    Wie hast du die IWindowBase als Interface und nicht als mustinherit Class definiert? ich frage deswegen, da ich noch nie mit Interfaces gearbeitet habe und bisher alles normal über Vererbung hingekriegt habe und auch das vormalige Interface oben nun normal als Klasse angelegt habe, die ich an die ganzen ChildWindowVM weitervererbe

    Ich markiere hier mal als gelöst. Danke für die Hilfe

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „SKeks“ ()

    Hallo @SKeks

    Sorry das ich dir das mit den Messages noch nicht gemacht habe. Echt viel zu tun im Moment. Habe aber nicht vergessen.
    Ein Interface deshalb weil das ViewModel die Klasse wo du dann das Fenster aufmachst (im Projekt mit der App) ja nicht kennen darf.

    Schau dir mal das an. Echt Interessant.
    ​Ist zwar jetzt nicht tiefer erklärt aber man kann ganz gut verstehen wofür diese Grundlegend sind.
    blog.codeinside.eu/2007/11/28/…auf-simple-art-und-weise/
    ​Aber wenn du anfängst z.b. Pluginschnittstellen zu Programmieren usw. oder Remoting dann lernst du Interfaces ganz gut kennen.

    Mahlzeit
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##

    Dann müsstest du im VM aber einen Verweis auf die exe haben. Probiers mal!!
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ## Bitte markiere einen Thread als "Erledigt" wenn deine Frage beantwortet wurde. ##