DataGridView.Columns[].Contains Möglichkeit

[Arne Drews]

Hi,

Ich such nach einer schmalen Lösung, innerhalb einer DataGridViewColumn einen bestimmten Wert zu suchen.
Den Weg über eine Iteration der DataGridView.Rows finde ich ein wenig unsexy.

Bevor ich mir nun eine eigene Search-Methode entwickle, wollte ich mal fragen, ob ich eine bestehende Möglichkeit nur übersehe?

Meine Vorstellung wäre ähnlich folgender Funktionsweise:
[highlight=csharp]bool bExists = DataGridView1.Columns["spalte"].Contains( "wert" );[/highlight]

Vielleicht gibt es ja so was ähnliches bereits?
Gefunden habe ich leider nichts.

Danke

[Ralf Jansen]

Daten stecken in den Row Objekten die, Column Objekte sind reine Beschreibungen der Spalten.
Wenn du an einen Wert willst musst du also über die >Rows iterieren und jeweils die passende Cell anschauen.

Unsexy finde ich übrigens das am Grid zu machen und nicht an der Datenstruktur mit dem das Grid befüllt wurde. Da gehört sowas hin und mit der richtigen Datenstruktur wird sowas ganz einfach. Wenn du die Daten direkt einzeln in das Grid ~geschossen~ hast solltest du das nochmal überdenken.

[Arne Drews]

Hi,

Ich übertrage Daten aus einem Grid in ein zweites. Im ersten Grid stehen unterschiedliche Artikelvarianten zur Auswahl, die per Schaltfläche in ein weiteres Grid übernommen werden.
Nur die Daten aus dem zweiten Grid werden am Schluss auch wirklich verarbeitet.

Um nun zu verhindern, dass man versehentlich die gleiche Artikelvariante nochmal in das zweite Grid übernimmt, muss ich feststellen, ob diese darin schon enthalten ist.
Ist nur eine "Schönheits"-Anforderung, aber durchaus Praxis, denke ich.

Die Daten zusätzlich in einer Datenstruktur zu verwalten, halte ich für overdressed, weil ich für die Visualität auch immer wieder live die zweite Grid aktualisieren muss.
Eine vorangestellte Datenhaltung ohne die Grid kommt nicht in Frage, weil live gesehen werden soll, was zur Verarbeitung ausgewählt wurde.

Wenn es dann die einzige Möglichkeit ist, über die Rows zu iterieren, muss ich das wohl so machen, danke für Deine Infos.

Gruß Arne

[defo]

Um nun zu verhindern, dass man versehentlich die gleiche Artikelvariante nochmal in das zweite Grid übernimmt, muss ich feststellen, ob diese darin schon enthalten ist.
..
Die Daten zusätzlich in einer Datenstruktur zu verwalten, halte ich für overdressed, weil ich für die Visualität auch immer wieder live die zweite Grid aktualisieren muss.

Um Doppelungen zu vermeiden würde man doch klassische bei Selektion / Übertragung ein Move machen statt eines Copy. Dann kann man nichts doppelt eintragen. Analog müssen irrtümlich selektierte Sätze natürlich wieder zurück befördert werden.

Mit Datenstruktur meinst Du was?
Auch wenn es Dir offenbar nicht so schmeckt. Die Selektion in eine Servertabelle zu schreiben (plus Session ID) und mit Deinen Standardverfahren im 2. Grid anzuzeigen wäre keine Idee? Ja, muss man aktualisieren, aber ich habe schon schlimmeres programmiert als ein Grid Refresh.

Im Ganzen gesehen hat es eine Menge Vorteile finde ich:
- Plain Standard Vorgehen (mit entsprechendem Einsatz von Standardprogrammstrukturen und Möglichkeiten)
- Einfache "Dublettenüberwachung" oder jegliche andere Form von
- Constraintüberwachung bis hin zu
- transparenten SQL Suchmöglichkeiten
- oder so "krassen" Sachen wie Vieraugenprinzip usw.

[Arne Drews]

Mag sein, dass das die bessere Variante ist, aber ich bin mir nicht sicher, ob das auch wirklich auf meinen Anwendungsfall zutrifft.
Ich lasse mich aber gern eines besseren belehren und detailliere hier noch mal, was ich genau mache.
Dann könnt ihr mir vielleicht ja sagen, ob das wirklich "lohnt".

Ich häng mal zur besseren Erklärung einen Screenshot unten ran.

• Grid1: das kleine auf der linken Seite
• Grid2: das große rechts

Wofür das ganze?
Wir möchten Artikel in ein externes Lager eines Sepditeurs auslagern, da unserer Lagerkapazitäten derzeit nicht mehr ausreichen.
Dazu habe ich die Schnittstelle des Spediteurs eingebunden, über die ich die Ware immer anmelde, bevor wir sie auslagern.

Nun möchte ich es für unseren Lageristen etwas vereinfachen und habe deshalb die Maske im Anhang erstellt.
Im Feld "Artikelnummer" gibt er eine Artikelnummer ein. Mit dem Wert des Feldes wird über das TextChanged-Event ein passender Eintrag in der DB gesucht, woraufhin die entsprechenden Varianten dann im Grid1 dargestellt werden.
Im Grid 1 steht pro Variante die Möglichkeit zur Verfügung, die Menge anzupassen, die ausgelagert werden soll.

Mit Klick auf Übernehmen, wird die in Grid1 gemachte Auswahl an Grid2 übertragen. Übertragen werden natürlich nur die, die eine Menge > 0 haben und deren Verfügbarkeit > der eingetragenen Menge ist.
Das wird im einzelnen noch gekennzeichnet, damit man das überarbeiten kann, falls es sich um ein Versehen handelt, aber das ist hier irrelevant, denke ich.

Am Ende wird mit Klick auf Fertigstellen das ganze automatisch in einen speziellen Auslieferungsbeleg übernommen, entsprechende Lageruchungen vorgenommen und die Ware über die Schnittstelle bei der Spedition angemeldet.


Jetzt kommt das eigentlich Problem:
Sobald der Benutzer nun einen anderen Artikel oben eingibt, wird auch Grid1 neu gefüllt. Fällt dem Benutzer später ein, dass er von Artikel 123 doch noch ein paar auslagern möchte.
Also tippt er die Artikelnummer ein, stellt die Mengen im Grid1 ein und klickt auf Übernehmen.

Jetzt muss ich prüfen, ob die Variante des Artikels bereits in Grid2 vorhanden ist.
Nach der Antwort von Ralf bin ich weiterhin der Meinung, dass ich am besten über die Rows der Grid iteriere und auf Artikelnummer und Ausprägung prüfe.
Ob ich Move oder Copy an der Stelle verwende, dürfte für den Fall relativ gleich sein, denke ich?

Grundsätzlich funktioniert auch alles! Mir ging es rein um eine elegantere Lösung, um zu prüfen, ob ein Artikel schon in der Grid2 vorhanden ist.
Sollte ein anderer Weg deutlich besser sein, wäre ich über Details dankbar.


Vielleicht noch erwähnenswert:
Ich habe das nicht über eine Datenverbindung im Projekt gelöst, sondern direkt im Code.
Hat der Weg über die Datenverbindung Vorteile in Bezug auf die Dubletten in Grid2?

Danke für eure Hinweise.
Gruß Arne

[defo]

Wenn bei der Verarbeitung die Menge ins Spiel kommt und die Datensätze nicht vollständig umgelagert werden, dann macht das Move versus Copy Thema nicht wirklich Sinn.
Für ein komplettes Handling im Backend, also persistente Verwaltung der Umlagerdaten (Grid2) spricht auch der ganze Prozess an sich. Es ist ja offenbar eben nicht nur ein Auslagern, sondern Teil eines Prozesses, der zwischen beliebigen Lagern geschehen kann.
Transparenz, Nachvollziehbarkeit, Auswertungen, Fehlerkorrektur, .. sprechen m.E. für eine Modellierung. Grid 1 wäre dann mehr oder weniger wirklich nur eine Suchmaske. Grid 2 ein View auf geplante/offene oder historische Umlagerdaten.

Die Implementierung wäre dann im Frontend eine Suchmaske plus Insert, Update, Delete in den Lager"transaktionen (Grid2), plus Nachverarbeitung per Trigger oder SP für die eigentliche Durchführung der Aktion zwischen 2 (oder mehr) Lagern die in Grid 2 vorgegeben ist.

Wie gesagt, Ziel des Vorgehens wäre eine konsistente Lösung mit Standard Entwicklungs Verfahren und Vermeidung der Suchaktion in Grid oder Datatable / Dataset Daten.

[Arne Drews]

Hi,

danke für Deine Mühen.

Grid 1 wäre dann mehr oder weniger wirklich nur eine Suchmaske. Grid 2 ein View auf geplante/offene oder historische Umlagerdaten.

Ja genau, Grid1 wäre hier nur eine Suchmaske, das beschreibt es glaube ich besser, danke.
Die Daten, die für die Umlagerung in Grid2 gesammelt werden, gelten nur für ein einziges Ziellager, daher hält sich die Historie in Grenzen.
Das Umlagern passiert eh noch nicht bei der Übergabe an Grid2, sondern bei finalem Klick auf die Schaltfläche Fertigstellen. Das hat den Grund, dass ich Grid2 eigentlich nur als Übersicht benötige, damit man dort evtl. noch etwas anpassen kann, bspw. die Menge oder einen Datensatz nachträglich noch zu entfernen.

Wie gesagt, Ziel des Vorgehens wäre eine konsistente Lösung mit Standard Entwicklungs Verfahren und Vermeidung der Suchaktion in Grid oder Datatable / Dataset Daten.

Du hast sicher recht damit, danke für die Hinweise!
Ich muss schauen, ob ich das dahingehend umbaue oder ob mir das auf diese Art doch reicht.
Es arbeitet derzeit ziemlich performant im Gegensatz zu unserer eingesetzten Warenwirtschaft.

Danke und schöne Grüße
Arne Drews