C# DataGrid bestimtme Zeile in anderes DataGrid kopieren

[Mijay]

DataGrid bestimmte Zeile in anderes DataGrid kopieren

Hallo zusammen,

ich glaube das wird nicht die letzte Frage zum DataGrid von mir bleiben befürchte ich.
Folgende Situation:

2 DataGrids, 2 List<T> mit Objekten

Hinter DataGrid1 befindet sich List1<T> und hinter DataGrid2 befindet sich List2<T> als Quelle.
In DataGrid1 befindet sich mein "Datenpool" (dort werden alle ermittelten Daten dargestellt). Aus diesem Datenpool möchte ich eine bestimmte Zeile (Objekt) in die List2<T> kopieren und in DataGrid2 anzeigen. Dabei soll das Objekt in List1<T> nicht gelöscht werden! Wichtig!
Wie bekomme ich heraus, welche Zeile selektiert wurde? Wenn ich das rausbekomme, hab ich ja automatisch auch das Objekt an dieser Stelle z.B. DataGrid1 Zeile 2 markiert = List1<T>[1]
Als Bonus würde ich das gerne mit mehreren Zeilen durchführen können (erstmal nicht so wichtig).
Vielleicht gibt es auch ganz andere tolle Wege, habe da was mit DataTables gelesen, aber keine Ahnung, ob das schon wieder viel zu mächtig ist, denn ich rede von maximal 25 Objekten in List1<T> (das ist schon hoch gegriffen denk ich, eher 5-10).

Gruß
Mijay

 

[HaGGi.13]

Die Eigenschaft SelectedRows vom DataGridView

 

[Rossibaer]

MSDN DataGridView.SelectedRows

Alternativ könntest du auch durch die Rows Collection mit einer "for" Schleife gehen und einzeln prüfen ob ausgewählt oder nicht, siehe MSDN DataGridViewRow.Selected

Bei DataTables müsstest du jetzt deinen bisherigen Binding Mechanismus ändern, d.h. nicht mehr das Grid an eine List sondern an DataTable Objekt binden und dann dennoch über o.a. Möglichkeiten die Zeilen rausziehen und transferieren. Desweiteren kann eine DataRow nicht 2 DataTables angehören. DataTables sind in meinen Augen zu viel des Guten, da hier saumässig viel zusätzliche Funktionalität mit drin steckt die wahrscheinlich nicht notwendig ist. Ist aber nur eine Vermutung meinerseits, ohne dein Projekt genauer zu kennen. Verwendung für DataTables habe ich zur Zeit nur, wenn ich direkt mit einer Datenbank kommuniziere und das Resultset irgendwo bereit halten will. (Bitte kommt jetzt nicht mit LINQ!)

Ach ja eine Zeile in einem DataGridView ist nicht das gleiche Objekt deiner Liste. Das sind 2 unterschiedliche Objekte. Also bleibt in meinen Augen wahrscheinlich nur die Möglichkeit den Index der ausgewählten Zeile zu ermitteln um dann in deiner Liste diesen Index zu verwenden um das Objekt zu referenzieren. Wie es mit der Sortierung aussieht, wenn das Sortieren durch Anklicken des Spaltenheaders möglich ist, steht dann auf einem anderen Blatt Papier, aber Versuch macht klug...

 

[Mijay]

@ HaGGi.13
mit selectedRows bekomme ich doch nur die Anzahl der selektierten Zeilen zurück?!? Zumindest habe ich es so verstanden.
Eine Zeile markiert -> SelectedRows = 1
Zwei Zeilen markiert -> SelectedRows = 2

Dachte eigentlich darüber könnte ich es machen (hatte das heute schonmal probiert), aber anscheinend nicht??

@Rossibaer
Mit DataGridViewRow hab ich gegen Feierabend n bisschen rumgespielt, aber nicht weiter probiert. Dann werd ich damit mal morgen weiter machen. Sortieren ist von Anfang an deaktiviert Macht in meinem Fall keinen Sinn. Mit dem Index das hatte ich auch so im Hinterkopf gehabt.
Ich glaube so langsam komme ich in die richtige Richtung mitm programmieren

 

[toeffi]

... (Bitte kommt jetzt nicht mit LINQ!)....

Wieso nicht? Was spricht dagegen

 

[HaGGi.13]

Du solltest dir mal SelectedRows genauer angucken... -_-

Das ist eine Collection deiner ausgewählten Zeilen im Grid.

Also kannst du die mit einer foreach iterieren und hast dann wirklich nur deine ausgewählten... Zudem hat jedes Element dann die Eigenschaft Index mit der du auch den Index bekommst.

 

[Rossibaer]

@Mijay: siehe Haggi.13 Kommentar und lies dir die Doku von MSDN mal genauer durch.

@toeffi:
Ohne mich da jetzt zu weit aus dem Fenster hängen zu wollen, sehe ich LINQ nur als eine weitere Schicht zwischen der Datenbank und Programmierer. Was für mich nicht in Frage kommt! Was MS allein schon mit dem DataAdapter und CommandBuilder in früheren .Net Versionen bereits verbrochen hat...

Ich weiß, es sind 2 unterschiedliche Dinge! Jedoch sehe ich nunmal eine WHERE Bedingung über alle Spalten mit endlosen AND und OR Verknüpfungen nicht als eine Lösung an um die Erkennung von Multiuserkonflikten sicherstellen zu können. Abgesehen von der Performance, da hier der Optimizer der DBMS vollständig ausgehebelt wird. Wie sieht das aber nun bei LINQ aus?

Entweder ich verwende die SubmitChanges() Methode oder ich überschreibe es durch folgendes (Beispiel aus DLinq_Overview_for_CSharp_Developers.doc):

public partial class Northwind : DataContext
{
	[UpdateMethod]
	public void OnProductUpdate(Product original, Product current) {
		// Execute the stored procedure for UnitsInStock update
		if (original.UnitsInStock != current.UnitsInStock) {
			int rowCount = this.ExecuteCommand(
				"exec UpdateProductStock " +
				"@id={0}, @originalUnits={1}, @decrement={2}",
				original.ProductID,
				original.UnitsInStock,
				(original.UnitsInStock - current.UnitsInStock)
			);
			if (rowCount < 1)
				throw new OptimisticConcurrencyException();
		}
	}
}

Wo ist der Vorteil von LINQ? Entweder ich verlasse mich darauf das MS riesige Update-Befehle generiert mit WHERE Bedingungen, die bei Tabellen mit vielen Spalten jeden Optimizer verzweifeln lässt oder ich hacke meine Updates wie gewohnt in SQL-Strings. Bei dem automatisch generierten Befehlen würde ich mal vermuten, das auch jede Spalte unabhängig - ob geändert oder nicht - in den SET Bereich mit aufgeführt wird. Das läßt nix gute ahnen.

Schlagt mich für meine oberflächliche Sichtweise, berichtigt mich falls ich falsch liege und doch nur ein weiterer Nostalgiker bin, aber das ist alles Off-Topic und sollte wohl besser nicht in diesem Thread diskutiert werden.

 

[toeffi]

Naja die Sache ist folgende, es geht hier zum einen darum wie man dem Programmierer ein einfaches und "bekanntes" Interface zur Verfügung stellt, und es ist schon was feines wenn man

NorthwindContext con = new NorthwindContext();

var allPersons = from p in con.Personen
                          where p.Id = "irgendwas"
                          select p;
//tralala keine ahnung ob es PErsonen in der Northwind Datenbank gibt, aber darum gehts auch nicht, sondern um die logik die präsentiert werden soll.
//tralala mache was wunderbares mit allen Personen

zu schreiben als eine SQL Anweisung, das Command vorzubereiten, das Commandobjekt mit Parametern zu bestücken, und diesen gegen die Datenbank zu schicken, besonders weil du keine einfache IEnumerable zurück bekommst sondern einen SQLDataReader. Schau dir mal NHibernate an, das ist das selbe Prinzip.
Was die Performance angeht, mach dir da mal keine Sorgen, verwendet man den Kontext korrekt, und arbeitet mit Lazy Loading, bzw lädt sich diverse Entitäten einfach mit beim Laden anderer mit rein, so ist das schon gut schnell.(Hier ein Beitrag von mir dazu, kannst du dir ja mal durchlesen wenn du magst.Lazy Loading mit Linq-To-SQL
Du hast ein komplettes Objekt Releation Modell von der Datenbank in dein PRojekt projeziert bekommen, was dich den Grad der Objektorientierung massiv steigern lässt.
Das CRUD Prinzip ist durch LINQ-To-SQL wesentlich intuitiver, weil du eben auf dem Objektmodell arbeitest. Wenn du noch mehr Infos brauchst oder dich was spezielles interessiert, schreib mir einfach ne Pn dann diskutieren wir das dort aus Aber ich hoffe das konnte deine Frage beantworten, zumal ich nicht ganz wusste was du meinst

 

[Mijay]

Habs mit SelectedRows hinbekommen. Ich werde mir angewöhnen mehr mit der Hilfe zu arbeiten. Da steht ja doch erstaunlich gut alles erklärt drin (was ja nicht immer der Fall bei Hilfen ist...).

Danke an Alle :-)