Laden...

Zugriff auf Property einer anderen Klasse/ViewModel

Erstellt von echdeneth vor 3 Jahren Letzter Beitrag vor 3 Jahren 2.810 Views
Thema geschlossen
echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren
Zugriff auf Property einer anderen Klasse/ViewModel

In meinem MVVM-Projekt, habe ich ein "kleines" Problem.

Ich habe ein MainViewModel mit einem solchen Aufbau:


public class MainViewModel : BaseViewModel
    {
        public ICommand CommandClose { get; set; }
        public ICommand CommandMax { get; set; }
        public ICommand CommandMin { get; set; }

        public MainViewModel()
        {
            CommandClose = new RelayCommand(CommandClose_OnClick);
            CommandMax = new RelayCommand(CommandMax_OnClick);
            CommandMin = new RelayCommand(CommandMin_OnClick);

            CurrentViewModel = new RechnungenView();
        }

        private object _currentViewModel;
        public object CurrentViewModel
        {
            get { return _currentViewModel; }
            set
            {
                if (_currentViewModel != value)
                {
                    _currentViewModel = value;
                    NotifyPropertyChanged();
                }
            }
        }

CurrentViewModel hängt an einem ContentPresenter der verschiedene Views darstellt.

Nun kann ich aus den zuugehörigen ViewModels der Views nicht auf CurrentViewModel zugreifen
um ein anderes ViewModel anzeigen zu lassen.

Die Views sind in obigen Beispiel UserControl.

Und egal wie ich es Drehe und Wende, ob ich Pages verwende - ich bekomme keine Navigation zustande.
D.h. ich möchte aus einem Usercontrol oder einer Page den Content des ContentPresenters oder einer Frame ändern.

Diverse Codes im Netz sind mit noch viel zu hoch. Gibt es verständliche Lösungen?

Danke

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

4.931 Beiträge seit 2008
vor 3 Jahren

Dein MainViewModel kennt ja alle anderen ViewModels, daher benutze in diesen VMs ein Ereignis, das von dem MainViewModel abonniert wird und den Austausch des CurrentViewModel durchführt.

Statt object solltest du eine Basisklasse (oder zumindestens ein interface) für deine VMs verwenden (und dort definierst du dann obiges Ereignis).

2.078 Beiträge seit 2012
vor 3 Jahren

Oder anders herum:

Jeder Dialog, der navigieren können möchte, bekommt ein Objekt vom Typ INavigationService.
Die Implementierung ist dann z.B. das MainViewModel.

Das hätte den Vorteil, dass man nicht jedes DialogViewModel dazu zwingt, ein Interface zu implementieren, was früher oder später nervig werden könnte - z.B. wenn man etwas an der Navigation ändern möchte.

Abgesehen davon versuche ich bei der Kommunikation zwischen den ViewModels auf Events zu verzichten.
Zum Einen sind asynchrone Abläufe damit nur schwer umzusetzen und zum Anderen führt das schnell zu sehr unübersichtlichen Verkettungen, die man - weil Event - kaum überblicken kann.

PS:
Ich würde mir aber auch nochmal genau überlegen, ob object der richtige Typ für die Property ist.
Ich behaupte einfach mal, dass diese ViewModels Gemeinsamkeiten haben oder haben werden, daher lohnt sich eine gemeinsame Basis.
Ich würde daraus z.B. eine "DialogBaseViewModel"-Klasse machen, dann könntest Du darin z.B. sowas wie einen Fenster-Titel pro Dialog realisieren.

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

...benutze in diesen VMs ein Ereignis, das von dem MainViewModel abonniert wird und den Austausch des CurrentViewModel durchführt.

Hier muss ich passen da ich in MVVM noch keine Erfahrung im Event-Handling habe.

Statt object solltest du eine Basisklasse (oder zumindestens ein interface) für deine VMs verwenden (und dort definierst du dann obiges Ereignis).

Ist dieser Link so was in der Richtung?
MVVM – Hierarchies & Navigation
Etwa mittig auf der Seite, der Teil mit der BindableBase
Ich mühe mich das peu a peu nachzubauen, und hoffe es zu verstehen...

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

... bekommt ein Objekt vom Typ INavigationService.
Die Implementierung ist dann z.B. das MainViewModel...

INavigationService Ist das nicht MVVMlight?

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

2.078 Beiträge seit 2012
vor 3 Jahren

Das Thema Events hat prinzipiell nichts mit MVVM zu tun, die ViewModels können untereinander kommunizieren, wie sonst auch. MVVM beschreibt nur die Trennung von View und ViewModel.
Dabei sind allerdings ein paar ausgewählte Events wichtig, wie z.B. PropertyChanged

Und die BindableBase ist eine mögliche Basis-Implementierung, die das ganze Thema um das PropertyChanged-Event übernimmt.
Bei mir hieß das bisher immer ObservableObject, angelehnt an ObservableCollection.

Und ob INavigationService vom MVVMLight ist, weiß ich nicht, ich selber nutze dieses Framework nicht. Das Konzept ist aber nicht neu, daher kann das schon sein.

Ob für dich nun die Umsetzung von MVVMLight sinnvoll ist, kann ich dir nicht sagen.
Ich hätte vermutlich Methoden wie NavigateTo(object viewModel) und NavigateBack() eingebaut.

4.931 Beiträge seit 2008
vor 3 Jahren

Palladin007, ja ist wahrscheinlich besser hier mit einem injizierten Navigationsinterface (Persönlich finde ich aber die Trennung bei Events besser gelöst).

echdeneth: Damit ist nur gemeint, daß du selber ein Interface namens INavigationService bereitstellst (wenn du eben kein MVVM-Framework benutzen möchtest), bei der du die benötigten Eigenschaften und Methoden definierst.
Und dein MainViewModel implementiert dann diese Schnittstelle und gibt sie an die Sub-VMs weiter:


public class MainViewModel : BaseViewModel, INavigationService
{
    public MainViewModel()
    {
        CurrentViewModel = new RechnungenView(this); // <-- hier gibst du die Schnittstelle an die Sub-VMs weiter
    }
}

Und in den Sub-VMs nimmst du dann diese Schnittstelle entgegen und führst die Methoden oder Eigenschaften aus:


public class RechnungenView : BaseViewModel
{
    public RechnungenView(INavigationService navigationService)
    {
        _navigationService = navigationService; // am besten dies in die Basisklasse packen - evtl. als NavigationBaseViewModel
    }

    void SomeMethod()
    {
      _navigationService.NavigateBack(); // for example
    }

     private INavigationService _navigationService;
}

2.078 Beiträge seit 2012
vor 3 Jahren

Ja, die Trennung bei Events ist sehr lose, das kann ein Vorteil sein, aber auch ganz gewaltig nach hinten losgehen.

Ich hatte schon mehrere Fälle, bei denen viele Events sich nacheinander aufgerufen haben. Das kann zu lustigen Fehlern führen, wie eine Endlosschleife/StackOverflowException oder eine Methode zerstört durch komische Event-Verkettungen den eigenen Stand.
Ich würde unvorsichtig genutzte Events schon fast auf Höhe von Application.DoEvents() sehen.

Abgesehen davon können Events kein async bzw. schon, aber nur so halb und wenn man noch awaiten will, muss man sich mit das übliche EventHandler-Pattern verlassen und Tasks zurück geben. Letzteres geht zwar, aber dann muss man die EventHandler selber verwalten.

Und dann noch das Memory-Leak-Risiko...
Und wenn Du solche Fehler suchst, musst Du eigentlich Zeile für Zeile durch debuggen, weil man dem Event nicht ansieht, was dahinter steckt.

Deshalb der Rat, bei Events sehr, sehr vorsichtig zu sein 😃
Sie können toll sein, aber die Vorteile können ganz gewaltig nach hinten los gehen.

Wirklich sinnvoll finde ich sie nur, wenn man unbedingt eine 100% lose Trennung zwingend braucht. Wie eben bei der Trennung View/ViewModel, wo die View sich sowohl technisch als auch strukturell extrem vom ViewModel unterscheidet.
Das Binding-System über ein Service-Interface zu realisieren wäre ja so gut wie unmöglich, da pro Property völlig andere Implementierungen oder sogar mehrere Implementierungen möglich sind.

5.657 Beiträge seit 2006
vor 3 Jahren

Ist das nicht in etwa das gleiche Problem wie Wie implementiere ich einen Zurück-Button in einer App-Navigation mit MVVM??

Hier muss ich passen da ich in MVVM noch keine Erfahrung im Event-Handling habe.

Events haben nichts mit MVVM zu tin, das sind einfach Grundlagen von C#. Siehe dazu: [FAQ] Eigenen Event definieren / Information zu Events (Ereignis/Ereignisse)

Weeks of programming can save you hours of planning

4.931 Beiträge seit 2008
vor 3 Jahren

Stimmt, den hatten wir ja neulich erst.

PS: Warum werden bei den Links bei dir die Titel nicht angezeigt (sollte doch eigentlich automatisch die Forensoftware durchführen)?

5.657 Beiträge seit 2006
vor 3 Jahren

PS: Warum werden bei den Links bei dir die Titel nicht angezeigt (sollte doch eigentlich automatisch die Forensoftware durchführen)?

Gute Frage und guter Hinweis. Offenbar werden die Links nicht automatisch umgewandelt, wenn sie man "www.mycharp.de" statt "mycharp.de" verwendet. Ich hab das mal angepaßt.

Weeks of programming can save you hours of planning

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

Bin den Artikel mit den Events durchgegangen und den Code nach bestem Wissen und Gewissen eingebaut.

Leider funzt es nicht X( Events feuern nicht oder werden nicht an MainViewModel weitergegeben.

Kann ich feststellen ob das Event gefeuert wurde?

MyEvent?.Invoke(this, e);

Das MainViewModel sieht dann so aus:

    
public class MainViewModel : BaseViewModel
    {
        private RechnungenViewModel rechnungenViewModel = new RechnungenViewModel();
        private RechnungViewModel rechnungViewModel = new RechnungViewModel();

        public MainViewModel()
        {

            rechnungViewModel.MyEvent += rechnungen_MyEvent;
            rechnungenViewModel.MyEvent += rechnung_MyEvent;

            CurrentViewModel = new RechnungView();
            Message = "MainViewModel";
        }


        public void rechnungen_MyEvent(object objSender, EventArgs e)
        {
            CurrentViewModel = new RechnungView();
            Message = "rechnungen_MyEvent";
        }

        public void rechnung_MyEvent(object objSender, EventArgs e)
        {
            CurrentViewModel = new RechnungenView();
            Message = "rechnung_MyEvent";
        }

        private object _currentViewModel;
        public object CurrentViewModel
        {
            get { return _currentViewModel; }
            set
            {
                if (_currentViewModel != value)
                {
                    _currentViewModel = value;
                    OnPropertyChanged();
                }
            }
        }

        private string _message;
        public string Message
        {
            get => _message;
            set
            {
                if (_message != value)
                {
                    _message = value;
                    OnPropertyChanged();
                }
            }
        }
    }

Das Ding mit Message habe ich nur als Extra Kontrolle gemacht.

Auch habe ich versucht CurrentViewModel im BaseViewModel unterzubringen.
Aus dem MainViewModel heraus wurde der Content vom ContentPresenter
korrekt gesetzt.
Im "ChildViewModel" konnte CurrentViewModel sowohl angesprochen als auch gesetzt werden.
Es hat jedoch am Content des ContentPresenter nichts geändert. 🤔

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

4.931 Beiträge seit 2008
vor 3 Jahren

Kann es sein, daß du mit deinen VM-Instanzen durcheinanderkommst?

Wo verwendest du denn rechnungenViewModel und rechnungViewModel? Du benutzt doch immer noch new RechnungView() als CurrentViewModel...

PS: Wenn du CurrentViewModel im BaseViewModel unterbringst, dann hat aber jede davon abgeleitete Klasse (und deren Objekte) jeweils eigene Instanzen davon!
Daher nochmal der Hinweis auf das Interface.

Edit:
Und was mir noch dazu eingefallen ist: was ist RechnungView überhaupt für eine Klasse? Ich hoffe mal, es ist kein UI-Element, denn dann paßt dein ganzes Konzept nicht.
Das würde auch erklären, warum du object als Datentyp bei CurrentViewModel hast, aber dann sollte (bzw. muß) dort trotzdem ein ViewModel gesetzt werden.
Oder anders gefragt, wie instantiierst du bisher die Views und verknüpfst das jeweilige ViewModel damit?

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

RechnungenView/RechnungView sind UserControl
(Ja, ich hab's nicht so mit der Namensgebung... mea culpa)

Was Interface angeht habe ich noch nicht viel mit geübt, nun eigentlich fast gar nicht.
Kann sie somit nicht unterbringen. habe es mir aber vorgemerkt.

Zur Letzten Frage:

Binding des Views (RechnungenView(UserControl) z.B.) an das ViewModel:

<Window.DataContext>
   <local:MainViewModel/>
</Window.DataContext>
  
<!--</Zeugs>-->

<ContentPresenter Content="{Binding CurrentViewModel}"/>

... und zuweisen des ChildView's an CurrentViewModel


<UserControl x:Class="...Views.RechnungView">
    <UserControl.DataContext>
        <vm:RechnungViewModel/>
    </UserControl.DataContext>
    <Grid Background="White">
        <StackPanel>
            <Label Content="Rechnung"/>
            <Button Command="{Binding Command}" 
                    Content="Rechnungen" Width="100"/>
        </StackPanel>
    </Grid>
</UserControl>

Oder meintest du was anderes?

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

4.931 Beiträge seit 2008
vor 3 Jahren

Ja, das habe ich befürchtet, du instanziierst also UI-Elemente (UserControls) aus dem ViewModel heraus - das ist ein absolutes NoGo (in MVVM)! Darum ja auch der Hinweis auf den NavigationService.

Und zu

<ContentPresenter Content="{Binding CurrentViewModel}"/>

Du bindest hier aber bisher kein ViewModel, sondern ein UserControl!

Du könntest alternativ auch ein DataTemplate zur Verknüpfung zwischen VM und View benutzen: Switching between WPF XAML views using MVVM DataTemplate sowie Navigation mit WPF und MVVM.

Ich habe das Gefühl, dir fehlt der Grundgedanke bei MVVM (sowie einige grundlegende Programmierthemen, wie eben Interfaces).

PS: Dir ist hoffentlich klar, daß


<UserControl.DataContext>
    <vm:RechnungViewModel/>
</UserControl.DataContext>

ein eigenständiges, neues RechnungViewModel erzeugt, das nichts mit deinem in deiner MainViewModel erzeugten Instanz rechnungViewModel gemein hat -> so kannst du auch keine Events von dieser VM-Instanz empfangen.

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

... ein eigenständiges, neues RechnungViewModel erzeugt, das nichts mit deinem in deiner MainViewModel erzeugten Instanz rechnungViewModel gemein hat -> so kannst du auch keine Events von dieser VM-Instanz empfangen.

What the... 8o
Ich nahm an das damit die ++**Datenbindung ** ++zum ViewModel hergestellt wird....
Weshalb wird da ein neues Objekt erzeugt? Das ist widersinnig, grotesk gar!

... Du bindest hier aber bisher kein ViewModel, sondern ein UserControl!

ja, ist mir auch kürzlich aufgefallen. Stammt so in etwa aus einem Tutorial.
Die Property wird auch peu a peu in CurrentView (um)benannt.

... du instanziierst also UI-Elemente (UserControls) aus dem ViewModel heraus

Ja, auch hier sei bemerkt, dass ich als Vorlage Tutorials verwendete in denen das GENAU SO gemacht wurde.
Nach diesem Style:


        public ICommand Blabla { get; set; }

        public MainViewModel()
        {            
            Blabla = new RelayCommand(Blabla _OnClick);

            CurrentViewModel = new Bla();
        }


        private object _currentView;
        public object CurrentView
        {
            get => _currentView;
            set
            {
                if (_currentView != value)
                {

                    _currentView = value;
                    NotifyPropertyChanged();
                }
            }
        }


        void Blabla _OnClick(object obj)
        {
           CurrentViewModel = new Blabla();
        }

Es sei mal noch erwähnt, dass ich des MVVM noch nicht lange mächtig bin (bzw: Dachte zu sein). Nur CodeBehind bisher...

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

16.806 Beiträge seit 2008
vor 3 Jahren

Ich nahm an das damit die Datenbindung zum ViewModel hergestellt wird....

Dann müsste der Context ja hellsehen können 😉

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

Ich habe das Gefühl, dir fehlt der Grundgedanke bei MVVM (sowie einige grundlegende Programmierthemen, wie eben Interfaces).

Möglicherweise
Und ich dachte, ich hätt's langsam raus...

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

4.931 Beiträge seit 2008
vor 3 Jahren

Was sind das für Tutorials, in denen so ein "<Schimpfwort>" gezeigt wird (wahrscheinlich nach dem Motto: "Hauptsache es läuft"...)?
Das hat dann aber nichts mehr mit MVVM zu tun, denn es geht ja gerade darum die Views und die ViewModels voneinander zu trennen.

Edit:

Die Property wird auch peu a peu in CurrentView (um)benannt.

Lass das (!), verwende doch ersteinmal den (relativ) einfachen Ansatz mittels DataTemplate (dann hast du die Verknüpfung zwischen VM und View nur genau an einer Stelle und der Rest deines Codes ist ohne jede weitere Abhängigkeit zwischen View und VM).

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

Mach ich so wie im "technical-recipes" Link gezeigt.

Wie verfahre ich bei "Untermenüs"?
Also wenn ein UserControl wiederum ein ContentPresenter hätte wie im MainViewModel.
Oder ist das ebenfalls Murks?
Und besser die Unterseiten in's MainViewModel incl. ein paar Show-Effekte mit einbauen?

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

4.931 Beiträge seit 2008
vor 3 Jahren

Dann hat doch das UserControl auch wiederum ein eigenes ViewModel und du kannst genau so verfahren.

Ich weiß selber, daß der Schritt zum "richtigmachen" manchmal einem zu groß vorkommt, aber wenn es dann umgesetzt wurde, gibt das dann Endorphine frei (ich arbeite z.Z an einem UI-Framework und weiß, wie mühsam notwendige Umbauarbeiten sind - auch DataBinding steht bei mir auf der Agenda...).

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

Danke, ich meld mich wenn ich fertig bin. So oder so fertig.

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

5.657 Beiträge seit 2006
vor 3 Jahren

Wie verfahre ich bei "Untermenüs"?
Also wenn ein UserControl wiederum ein ContentPresenter hätte wie im MainViewModel.
Oder ist das ebenfalls Murks?
Und besser die Unterseiten in's MainViewModel incl. ein paar Show-Effekte mit einbauen?

Wie ich schon mehrmals erwähnt habe, sind UserControls in WPF meist nicht notwendig. DataTemplates reichen für einen solchen Anwendungsfall aus, bzw. bei hierarchischen Daten wie hier HierarchicalDataTemplates.

Und "Show-Effekte"? Keine Ahnung, was du damit meinst.

Danke, ich meld mich wenn ich fertig bin. So oder so fertig.

Ist vielleicht auch nicht die richtige Einstellung. Es scheint dir nicht klar zu sein, _warum _man das überhaupt macht. Ich würde empfehlen, erstmal das "warum" und "wie" zu verstehen, und erst dann Code zu schreiben.

Weeks of programming can save you hours of planning

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

Wie ich schon mehrmals erwähnt habe, sind UserControls in WPF meist nicht notwendig

Bin mir nicht ganz sicher wie du das meinst.
Mein Verständnis eines Programmaufbaus mit Unterseiten! ist:

Hauptseite -> Unterseite1
-> Unterseite2
...

Wobei Haupt- und Unterseite entweder Window/Page/UserControl sein können.

Zuerst (am Anfang) habe ich für alles ein neues Fenster geöffnet, dann habe ich Pages "entdeckt"
und nun UserControls.

Wenn es nun eine andere Art gäbe genau DASSELBE! zu tun wäre ich höchst interessiert.

Und "Show-Effekte"? Keine Ahnung, was du damit meinst.

Flapsig ausgedrückt: Es wird ein Element (z.B. DataGrid) angezeigt -> Button wird gedrückt
-> 1. Element wird ausgeblendet / 2. Element (z.B. Grid mit Formularfeldern) wird eingeblendet
Daher "Show-Effekt", da beide Elemente bereits vorhanden sind und nur der Eindruck eines Wechsels erzeugt wird.

Ist vielleicht auch nicht die richtige Einstellung

Wenn ich lernen will wie MVVM funktioniert, muss ich etwas haben woran/womit ich es lernen kann.
Bücher gibts keine gescheiten, YouTube?, Foren evtl. und! funktionierender Code den ich analysieren kann.
z.B. https://www.technical-recipes.com/2016/switching-between-wpf-xaml-views-using-mvvm-datatemplate/
Mir bleibt also kaum eine Wahl...

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

309 Beiträge seit 2020
vor 3 Jahren

Wenn ich lernen will wie MVVM funktioniert, muss ich etwas haben woran/womit ich es lernen kann.
Bücher gibts keine gescheiten, YouTube?, Foren evtl. und! funktionierender Code den ich analysieren kann..

Ich arbeite derzeit das Buch C# 8 mit Visual Studio 2019: Das umfassende Handbuch von Andreas Kühnel durch, da wird auch MVVM behandelt. Ich kann das Buch wirklich auch für die Festigung grundlegender Kenntnisse empfehlen. Vorallem noch mal die ausführliche Einarbeitung in delegates und Events dürfte da einiges erklären.

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

C# 8 mit Visual Studio 2019: Das umfassende Handbuch

Das klitzekleine Problem: da ich mit .NET Framework arbeite (.NET CORE gibts nicht mit Views oder?)
kann ich nur C# 7.3.

Ich weiss nicht ob mir das Buch da weiterhilft. Aber ein Nullbarer DateTime Datentyp fänd ich reizvoll.

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

309 Beiträge seit 2020
vor 3 Jahren

da ich mit .NET Framework arbeite (.NET CORE gibts nicht mit Views oder?)
kann ich nur C# 7.3.

Ich weiss nicht ob mir das Buch da weiterhilft.

Ich gehe mal davon aus dass es zwischen Version 7.3 und 8 keine solchen fundamentalen Änderungen gibt, dass du damit überhaupt nicht mehr klar kommst 😁 Du kannst das Buch theoretisch auch mit einer uralt Version durch machen, alle Neuerungen der Versionen sind angeführt.

Es ist nirgendwo aufgeführt dass das Buch ausschließlich mit .NET Core arbeitet? Ich denke für dich würde das eh keinen merkbaren Unterschied bei der Entwicklung machen.

P
441 Beiträge seit 2014
vor 3 Jahren

Denkt bitte an die Regelung eine Frage pro Thread.

Jeder Datentyp kann nullbar gemacht werden, durch ein

Nullable<DateTime>

oder

DateTime?

.
Fraglich ist, ob das notwendig ist, aber das ist von Fall zu Fall zu entscheiden.

Du kannst in .Net Core mit WPF genauso MVVM machen, wie ich .Net Framework.

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

... Jeder Datentyp kann nullbar gemacht werden...
...Fraglich ist, ob das notwendig ist, aber das ist von Fall zu Fall zu entscheiden...

Ich nahm an dies sei erst mit C# 8 möglich, so wurde es kommuniziert. ich gabe zu, ich hätte es ausprobieren müssen - mea culpa.

Es ist(wäre) notwendig bei SQL Anfragen, wenn ein sie NULL-Werte enthält oder (über JOIN) bestimmte Einträge in der verbnundenen Tabelle keine Übereinstimmung haben (dann stehen da NULL- Werte).
Da bräuchte ich diese Felder nicht umständlich "UnNULLen". Fragt sich ob die verwendeten Klassen (DataTable etwa) auch NULL verwenden können. Mal testen...

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

2.078 Beiträge seit 2012
vor 3 Jahren

Du meinst das "Nullable Reference Types"-Feature, das geht in eine andere Richtung, mit dem Ziel, NullReferenceExceptions zu vermeiden.

Nullable Value Types gibt's seit C# 2.0 und .NET 2.0

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

So, läuft ziemlich gut.
Nun ergaben sich 2 Probleme, ein kleines und ein größeres.
(Soll ich dafür nen neuen Thread aufmachen?)

Das kleine:
Ich muss auf meine geliebte SnackBar (von: MaterialDesignThemes) verzichten,
da ich die MVVM Bindung zum MessageQueue nicht geschissen kriege.
Die Dokumentation auf der Seite ist - für mich zumindest - sehr vage.

Ich habe das gerne für Fehler-, Update und andere Meldungen verwendet.

Das große:
Wenn ich auf einer Seite irgendein SQL DB-Update mache (neuer Eintrag/Update z.B:),
wird auf einer anderen Seite (nach Wechsel dahin) kein Update der ObservableCollection(OC) gemacht.
Nun würde ich gerne auf ein Update-Button verzichten. Soll/Kann/WäreEsWeiseWenn ich die OC
Disposable mache? Habe damit keine Erfahrung, nur flüchtig von gelesen.
Oder kann ich ein Neuladen der betreffenden Seite (UserControl) initiieren?

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

4.931 Beiträge seit 2008
vor 3 Jahren

Hast du denn nach den DB-Aktionen im ViewModel immer das passende OnPropertyChanged(nameof(ObservableCollectionPropertyName)) aufgerufen?
Wenn jede Seite sein eigenes VM (mit eigener ObservableCollection) hat, dann mußt du alle betreffenden Seiten aktualisieren (z.B. über das MainViewModel).

Und was klappt nicht beim Binden der MessageQueue (s.a. das Binding-Beispiel in WPF material design Snackbar duration)?

echdeneth Themenstarter:in
161 Beiträge seit 2019
vor 3 Jahren

Hast du denn nach den DB-Aktionen im ViewModel immer das passende OnPropertyChanged(nameof(ObservableCollectionPropertyName)) aufgerufen?

Funktioniert (anscheinend) nicht bei anderen ViewModels

Wenn jede Seite sein eigenes VM (mit eigener ObservableCollection) hat, dann mußt du alle betreffenden Seiten aktualisieren (z.B. über das MainViewModel).

Muss ich da nicht auf die entsprechende property zugreifen können?
Wahrscheinlich über Events, worin ich mehr Übung brauche...

Und was klappt nicht beim Binden der MessageQueue

Sorry funzt jetzt, Deppenfehler X(


// dieser Teil befindet sich zum Testen in einer Property
messageQueue.Enqueue("Test: " + i);
 i++;
isActive = "True"; // Property zum Aktivieren

private SnackbarMessageQueue messageQueue = new SnackbarMessageQueue();

public SnackbarMessageQueue MessageQueue
        {
            get => messageQueue;
            set => messageQueue = value;
        }

"Man muß die Dinge so einfach wie möglich machen. Aber nicht einfacher." Albert Einstein

5.657 Beiträge seit 2006
vor 3 Jahren

Ich mach hier mal zu, damit das nicht noch chaotischer wird.

Bitte beachte zukünftig [Hinweis] Wie poste ich richtig?, besonders Punkt 1.2 Nur ein Thema pro Thread und Punkt 2.1 Im richtigen Forum posten.

Die Hälfte deiner Fragen beziehen sich zudem auf absolute Grundlagen, die sich durch einen kurzen Blick in die Doku beantworten lassen würden. Siehe dazu [Tipp] Schau in die Doku! - Möglichkeiten der Informationsgewinnung

Weeks of programming can save you hours of planning

Thema geschlossen