Daten filtern in WPF

Hallo, ich arbeite mich seit längerem in WPF ein, habe davor mit den WinForm gearbeitet.
Nun habe ich eine Datenbank, von der ich daten aus einer View oder Tabelle auslese. Diese Daten würde ich gerne in Textboxen darstellen. Darin kann der User dann die Daten editieren und über diese Werte dann genauer filtern. Ich brache aber eine View wie bei Win Form die DataView, der ich dann einfache den Select-String übergebe. Und da haperts. Wie gestalte ich das mit der DataView? Ich muß die Daten aus der Tabelle ineine View kriegen, die dann zusätzlich an ein DataGrid gelangt, zur Visualisierung. Ich denke, wenn ich da mal ein paar Einblicke habe, kann ich probieren und so manches wird etwas schlüssiger in WPF für mich werden.

Hallo oehrle,

dieses Vorgehen ist suboptimal, da UI und Datenbankzugriffe vermischt werden. Das widerspricht Seperation of Concerns.

Ein besserer Weg wäre das nach einem UI-Muster wie zB MVVM zu erledigen. Schau dir das mal an und dann wirst du selbst den Lösungsweg finden.

mfG Gü

Danke für die Info. Habe mir das durchgelesen, klingt auch gut mit der automatischen aktualisieurg der daten und der völlig entkoppelten Visualisierung. Um das anwenden zu können oder zu beherrschen, muss ich mich wohl noch sehr weit rein knien. Ich würde das schon sehr gerne beherrschen !!
Nun aber muss ich sehen, dass ich erst mal eine Oberfläche für die Filterung der daten hin bekomme. Ich könnte das ja in WinForms machen, möchte aber in die neue Technik umsteigen !! Nun, es steht ja auch noch der Zeitdruck dahinter. Es gibt wohl unterschiede beim Filtern. Bei der BindingListCollectionView.CustomFilter kann man wohl nicht alle Quellen verwenden. Wenn ich aus einer Datenbank eine EF-Klasse erstelle und dann die Tabelle beim Laden der Oberfläche dem DataContext zuweise, kann diese anschleidend nicht gefiltert werden. Verwende ich ein DataSet (die Datenabank), dann kann ich filtern. Wie gesagt, bei WPF gibts viel mehr Umfang und das ordentliche zu finden (auch über Google) ist nicht immer so einfach.

Hallo oehrle,

ich kann nachvollziehen wie es dir geht.

Wenn du das EF verwendest kannst du den SELECT-String als Query für die Datenbank verweden. Das wäre ein Workaround der einfach umsetzbar ist.

mfG Gü

Ja, die Lage ist beschissen, aber nicht "hoffnungslos" 🤔 Bin gerade am probieren. Ich denke auch, das es fürs erste tut, wenn ich Select-Strings zusammenbaue und dann im EF oder DataSet absetze. Ich denke damit kann ich am flexibelsten reagieren. Diese daten muss ich dann halt immer einem DataContext oder einer *.ItemSource zuweisen.

LinQ hat da wohl auch wieder eher das Problem mit zusammengestzten Such-Strings. die ich nicht übergeben kann (ich habe so etwas jedenfalls noch nicht gesehen).

Habe nun außerdem noch festgestellt, das die gute alte DataView verwendet werden kann, da funktiooneirt ja auch der RowFilter, cool.

Ich habe aber nun ein Problem mit dem DataGrid. Ich benenne die Headerspalten um, mache aber mit Binding die Zuordnung zu de Bezeichnungen von der Tabelle im DataSet. Nun werden die Spalten alle korrekt angezeigt, mit den anderen "Namen" die ich zugewiesen habe. Nach diesen Spalten werden dann alle Spalten der Tabelle nochmals angezeigt, aber mit den Spaltennamen aus der DataSet-Tabelle. Wie bekomme ich die weg?

Hier mal noch die Übergabe an den DataContext:

public MainWindow()
        {
            InitializeComponent();

            //// dataSet und TableAd.-Instanz ertsellen
            dSet = new SQL_ReconditioningDataSet();
            heliTadap = new ParamHeliTableAdapter();

            //// Daten laden
            heliTadap.ClearBeforeFill = true;
            heliTadap.Fill(dSet.ParamHeli);

            //// DataView intanziieren und befüllen mit Filtervorgabe
            dView = new DataView(dSet.ParamHeli, "(PRAPA = -8000) OR (PRANR < 1000000 AND PRAPA = 0)", "ABM1,PDL", DataViewRowState.OriginalRows);

            //// DataView dem globalen DataContext übergeben
            this.DataContext = dView;
        }

Hallo!

Stelle hierfür

AutoGenerateColumns="False"

ein. Dann kriegst du nurnoch die Spalten, die du per Hand angegeben hast.

Supi, das passt. Danke dir. Jetzt muss ich noch ein DataTemplate erstellen.

Hallo, ich versuche im Moment zusätzlich MVVM zu verstehen. Da es sich für meine Anwendung anbieten würde (da Anwendung überschaubar).
Nun habe ich mir nach längerem Lesen ein Beispiel geschhnappt, und versuche meine Anwendung anzupassen. Erst mal läuft alles so weit. da ich TextBoxen habe und intern BErechnungen durchgeführt werden, muss ich nocheinen Converter einbinden. Meine Berechnungsmethode (erst mal zum testen) habe ich auch in der Klasse welche die Daten kapselt. Ist das so OK? Oder BEechnungen in eine statische Klasse auslagern? Dann noch zum Aufruf der BErechnungsmethode. Macht man das in der Regel über ein Command, oder ist das falsch?

Hallo oehrle,

Bitte beachte [Hinweis] Wie poste ich richtig? Punkt 1.2, daher gehe ich nur kurz auf deine Fragen ein.

muss ich nocheinen Converter einbinden

Sehe hier keinen Grund dazu. Lass doch das ViewModel (VM) die Daten konvertieren dass sie zur View passen. Das ist ja gerade die Aufgabe des VM.

Meine Berechnungsmethode (erst mal zum testen) habe ich auch in der Klasse welche die Daten kapselt

Wenn sie Teil der Klasse im Sinne von Verhalten + Zustand ist dann ja, wobei der Zustand die Daten sind. Wenn nicht erstell einen weitere Klasse. Letzteres wird wohl eher der Fall sein. Erstell also eine Klasse zB DataProcessor welche die Methoden zum Berechnen hat und als Argument verwendest du die Data-Klasse.
Eine statische Klasse ist auch nicht notwendig - i.d.R., genaueres kann ohne mehr Kenntnsi über deine Anwendung ja nicht gesagt werden.

Dann noch zum Aufruf der BErechnungsmethode. Macht man das in der Regel über ein Command

Im Endeffekt ja. Ob aber direkt der Aufruf des ICommand.Execute die Berechnung aufruft oder das ViewModel (dort ist das ICommand) erst nach anderen Methoden kann auch nicht gesagt werden.

Schau dir aber auch andere Beispiele zu diesem Thema an und bemühe die Forensuche dazu. Dieses Fragen wude allesamt schon mehrfach behandelt.

Dann ruf ich den 1. Satzt dieser Antwort noch in Erinnerung, sonst ist das Thema zu.

mfG Gü