Static Property - PropertyChanged für ItemsSource möglich?

Guten Morgen zusammen,

ich hab vor kurzem die Firma gewechselt und das Projekt was mir neu zugewiesen wurde, dort wurden fast nur static Propertys verwendet, meine Frage .. ist es möglich das ganze auch mit static Propertys auf PropertyChanged umzusetzen? Bevor ich alles umschreiben müsste?

Zuletzt hatte ich das Beispiel erfolgslos versucht :

        static DataHerstellung()
        {

            PropertyChanged += (sender, e) => { return; };

        }

        #region Definitionen

            //public static event PropertyChangedEventHandler PropertyChanged;

            public static event EventHandler PropertyChanged;



            private static int _List_Of_Validation_SelectedIndex;

            private static System.Collections.ObjectModel.ObservableCollection<List_Of_Validation> _ValidationEntrys;

        #endregion

        #region Struktur

         public struct List_Of_Validation
            {   
                public string Message { get; set; }    
                public bool Message_IsChecked { get; set; }
                public string Info { get; set; }
                public string Typ { get; set; }
            }

        #endregion


            public static System.Collections.ObjectModel.ObservableCollection<List_Of_Validation> ValidationEntrys
            {

                get
                {

                    return _ValidationEntrys;

                }
                set
                {

                    _ValidationEntrys = value;

                    OnPropertyChanged(EventArgs.Empty);

                }

            }

Hallo _Cashisclay,

wenn das möglich ist, dann nur mit fiesen hacks. Schreib es um. Ich will gar nicht wissen was es für Auswirkungen hat, wenn man versucht structs an die Gui zu binden.

Servus,

du meinst statics? Einen Struct innerhalb einer Liste sollte doch eigentlich kein Problem darstellen.

Nein ich meine schon die structs. Ich müsste jetzt tatsächlich lange nachdenken um mich zu erinnern, wann ich das letzte mal structs benutzt habe. Das Problem dabei ist ja, wenn du nicht explizit mit ref arbeitest, gibst Du immer eine Kopie von dem Object weiter. Wenn Du versuchst dann ein two-way binding zu benutzen, arbeitest Du im zweifelsfall nur auf der Kopie.

Benutze bitte in deinem eigenen Interesse besser POCO´s zur Datenhaltung.

Also es scheint zu funktionieren nur hat es mit Listen leider nicht funktioniert.

Hab jetzt mal eine DataTable benutzt und damit ging es dann, eigentlich wollte ich keine DataTable benutzen, weil ich mir dann immer erst meinen Eintrag suchen muss, jemand eine bessere Idee, welchen Typen ich verwenden könnte?

private static System.Data.DataTable _DataTable;

public static event EventHandler<PropertyChangedEventArgs> StaticPropertyChanged;

public static System.Data.DataTable DataTable
{
      get { return _DataTable; }
                set { _DataTable = value;
                NotifyStaticPropertyChanged("DataTable");
            }
}

            private static void NotifyStaticPropertyChanged(string PropertyName)
            {

                if (StaticPropertyChanged != null)
                {
                StaticPropertyChanged(null, new PropertyChangedEventArgs(PropertyName));
                }

            }

Ganz ehrlich, schmeiße den static-Kram raus - und wenn möglich auch das struct.
Und dann arbeite mit ObservableCollection etc.

Kleiner, allgemeiner Tipp:
In den meisten Fällen ist ein OnPropertyChanged bei einer Property vom Typ "ObservableCollection" nicht notwendig. Es sei denn, die komplette Property wird neu gesetzt.
Das Hinzufügen oder Löschen von Einträgen in der OC wird bereits durch die OC selbst überwacht.

Jup lag am struct, wusste ich nicht das es damit nicht geht, hab mir jetzt eine Klasse genommen damit funktioniert es.

Ich kann die Static Sachen nicht alle rauswerfen, das wäre aktuell einfach zu viel Aufwand, das muss ich nach und nach mal aufarbeiten.

Solchen Quellcode unbedingt mit großer Schrift ausdrucken, Blätter zu einer Rolle formen und den Urheber damit verhauen.

Ich persönlich kann damit auch nichts anfangen, würde so auch nicht schreiben, allerdings weiß ich auch nicht warum man das nicht machen sollte, also die Begründung .. ihr seid doch dort mehr bewandert, kann mich eventuell jemand aufklären?

Hallo _Cashisclay,

dazu solltest du dir mal anschauen, was static ist und was es macht. Es ist einfach alles immer vorhanden und jeder kann mit jedem. Das ist nicht das, was du in einer Software willst.

Ich müsste jetzt tatsächlich lange nachdenken um mich zu erinnern, wann ich das letzte mal structs benutzt habe.

Ich kann mich wie unconnected nicht daran erinnern, wann ich das letzte mal bewusst strucs verwendet habe und static dazu (Consolen Main Methoden (static) und Datetimes (struct) ausgenommen 😉

Gruss

Coffeebean

Kleiner, allgemeiner Tipp:
In den meisten Fällen ist ein OnPropertyChanged bei einer Property vom Typ "ObservableCollection" nicht notwendig. Es sei denn, die komplette Property wird neu gesetzt.
Das Hinzufügen oder Löschen von Einträgen in der OC wird bereits durch die OC selbst überwacht.

Gilt allerdings nicht für static, habs gerade nochmal probiert, aber ansonsten danke für die Info 😛
War mir aber zur ObservableCollection auch schon bekannt.

Deswegen nutzt man ja auch kein static.

Ich müsste jetzt tatsächlich lange nachdenken um mich zu erinnern, wann ich das letzte mal structs benutzt habe.

Ich kann mich wie unconnected nicht daran erinnern, wann ich das letzte mal bewusst strucs verwendet habe und static dazu (Consolen Main Methoden (static) und Datetimes (struct) ausgenommen 😉

Geht mir ähnlich static in dem Zusammenhang hab ich so auch nie benutzt, deswegen ist das ganze auch ein wenig umständlich gerade für mich. Struct war meine Idee, hatte das irgendwie im Hinterkopf und dachte, wozu gibts das Zeug, wenn ich es dafür nicht nutze, wusste aber nicht das es einfach überholt ist.

Deswegen nutzt man ja auch kein static.

Ja, aber ich kann es doch jetzt auch nicht ändern 😁

Hi _Cashisclay,

deinen letzten Kommentar verstehe ich nicht. Du hast doch gefragt, weil es nicht so funktioniert, wie es derzeit implementiert ist. Und der Grund, warum es nicht funktioniert, ist, daß es nicht korrekt implementiert ist. Man kann nicht einfach alles statisch und ohne Beachtung der grundlegenden Funktionsweisen von WPF implementieren, und dann erwarten, daß es von selbst funktioniert. Der Code ist so nicht funktionsfähig, nicht testbar, und nicht lesbar. Das gehört komplett neu implementiert da ist nichts zu retten.

Es ist auch nicht so schwer, wenn man einmal verstanden hat, wie es funktioniert. Ich empfehle daher [Artikel] MVVM und DataBinding und [Artikel] C#: Richtlinien für die Namensvergabe und [Artikel] Unit-Tests: Einführung in das Unit-Testing mit VisualStudio

Servus MrSparkle,

Hi _Cashisclay,

deinen letzten Kommentar verstehe ich nicht. Du hast doch gefragt, weil es nicht so funktioniert, wie es derzeit implementiert ist.

leider totaler Blödsinn ^^. Ich habe gefragt ob es so wie es aktuell implementiert es, die Möglichkeit besteht das ganze umzusetzen, was auch funktioniert, ich habe ja bereits den Lösungsquellcode gepostet.

Das Programm und auch die funktionsweise die ich mit dem aktuellen Stand umsetzen wollte funktioniert. Der Code ist funktionsfähig, ebenfalls testbar und auch lesbar, er mag zwar nicht so sein wie es sich gehört und das er neu geschrieben werden müsste, das möchte ich gar nicht abstreiten, aber ich hatte bereits geschrieben ich kann es nicht ändern.

Und um diesen Kommentar dir zu erklären -> Ich bin wie gesagt neu in der Firma, das Programm ist nicht klein, ich kann nicht einfach alles neu schreiben, das wäre ewig dauern .. ich muss nun mal damit erstmal arbeiten und das nach und nach anfassen.

Trotzdem danke für die Links, ich kenne allerdings das normale MVVM vorgehen, ich hätte auch nicht alles static deklariert bzw. hab ich das zuvor noch nie benutzt.

Grüße

Du schriebst:

Zuletzt hatte ich das Beispiel erfolgslos versucht

Was ist denn dann totaler Blödsinn, wenn man annimmt, daß es so nicht funktionert?

Stattdessen ein statisches Property mit DataTable zu verwenden ist auch keine Lösung, sondern ein schmutziger Hack mit unnötigem Overhead.

Jup lag am struct, wusste ich nicht das es damit nicht geht, hab mir jetzt eine Klasse genommen damit funktioniert es.

Ich kann die Static Sachen nicht alle rauswerfen, das wäre aktuell einfach zu viel Aufwand, das muss ich nach und nach mal aufarbeiten.

Weil ich hier zuletzt schrieb das es am struct lag warum es mit der ObservableCollection nicht funktioniert hat und es mittlerweile funktioniert, des halb ist es Blödsinn.

Außerdem ist es jawohl Geschmackssache ob man Daten eher in einer Liste als einer DataTable verarbeitet.

Außerdem ist es jawohl Geschmackssache ob man Daten eher in einer Liste als einer DataTable verarbeitet.

Nein. Ich würde jeden Kollegen der was neues (Du machst den Teil ja neu) mit DataTable anfängt vierteilen. Weil ich das im Zweifelsfall vielleicht mal warten müsste. Datatable(genauso wie die typisierte Variante) gehören in die Mottenkiste.

@_Cashisclay
Ich stimme unconnected zu!
Wenn man auf DataTables verzichten kann, sollte man es immer.
Auch der Speicherverbraucht zwischen einem DataTable und einer Liste ist ab einer gewissen Menge nicht zu unterschätzen.
DataTables liefern von Haus aus schon einen riesen Overhead mit und sollten wenn möglich vermieden werden.

Ich nutze DataTables nur noch für BulkInserts oder bei uralten Reports die eben ein DataTable als Quelle haben wollen.
Ansonsten wird alles in typisierten Listen gespeichert!

T-Virus