Charly_BOH schrieb:

Stichwort

DataTable.RowChanged - Event, mit e.Action = System.Data.DataRowAction.Add
Aber nicht googeln, sondern lern erstmal VisualStudio richtig nutzen (Google ist nicht deine Mami) und guck dir das dann im ObjectBrowser an.

Charly_BOH schrieb:

Wie mir der Link auf das YouTube-Video weiterhelfen soll, habe ich nicht so richtig verstanden.

Na, da werden doch alle möglichen VisualStudio-Features gezeigt.
Unter anderem der ObjectBrowser.
Der ObjectBrowser ist ein Tool, dass sämtliche Klassen deiner Solution und eingebundener Libraries dokumentiert.
Wenn man den kennt und benutzt erübrigt sich in 95% der Fälle die Konsultation von Google.
Ist das nicht klar geworden?

Charly_BOH schrieb:

Dass aber das gesuchte Ereigniss vom DataTable selbst ausgelöst wird, und dieses nicht einmal 'direkt' im Code angesprochen werden kann (geht ja nur über den 'Umweg' DataSet.DataTable.RowChanged und einem erstellten AddHandler) - dass muss man erst einmal wissen.

Ich arbeite sehr viel mit typDataset, und ich verwende für derlei Business-Logic die Code-Behind- Dateien des Datasets.
Das bringt eine Architektur, die BenutzerOberfläche und Datenschicht sauber getrennt hält.
"nicht einmal 'direkt'" kann man dann nicht mehr sagen, denn die Events werden dann durchaus direkt abonniert - nämlich im Dataset-CodeBehind - nicht im Form-CodeBehind.

Also du kannst mal im Dataset-Designer einen DoppelKlick auf eine Tabelle geben, dann öffnet sich der Dataset-Codebehind (ebenso wie sich der Form-CodeBehind öffnet, wenn du im Form-Designer ein Control doppelklickst).

Wenn du diese Art von Architektur interessant findest, kann ich mal ein Beispiel raussuchen.
Weil ich hab den Ansatz sehr umfangreich ausgebaut, mit einer sinnfälligen Ordnerstruktur und Kram.

Charly_BOH schrieb:

Beispiel wie man den an dieser Stelle nutzt

Naja - man kann den Code aussm Form ganz einfach in diesen Codebehind verlegen - dein Codebehind:Und nu kannste das Geraffel aussm Form-Codebehind entfernen.

Charly_BOH schrieb:

für den Einstieg nicht zu komplex

Das ist bischen ein Problem, weils zum Wesen von Architektur gehört, dass damit Probleme zu lösen sind, die durch zunehmende Komplexität auftreten.
So bis 300 Zeilen ist es tatsächlich die beste architektonische Lösung, den ganzen Kram im Form-Codebehind zu lassen.

Wenns mehr wird, dann muss man überlegen, ob man was auslagern kann in iwelche anderen Objekte, wo's sinnvoll ist.
Augenmerk auf "sinnvoll", weil manch eifriger Anfänger lagert vergleichsweise blindwütig alles mögliche aus, was aber garkein Sinn ergibt. Dann isses zwar schön ausgelagert, aber man findets nicht wieder, und Änderungen haben haufenweise komische Seiteneffekte.

Jedenfalls im Falle der Verarbeitung von DataTable-Events ergibt das sehr schön Sinn:
Das Form kann die DataTable-Events verarbeiten - hast du ja programmiert.
Aber die DataTable kann die DataTable-Events ebensogut verarbeiten - wenn nicht noch besser!
Auf jedenfall entlastet sie dadurch den Form-CodeBehind.

Ja, in meiner Erfahrung werden die Dinge aber noch komplexer, also recht bald wächst bei mir auch der Dataset-Codebehind zu.
Weil meine Datasetse habe schnell mehr als 10 Tabellen, und verarbeiten auch noch mehr Events, und Laden und Speichern hab ich auch meist Sonderwünsche,....
Und es gefällt mir sowieso nicht, dass dieser Code im Solution-Explorer so unsichtbar ist.
Weil dieser Code ist nix anderes, als was Code-Architekten mit ihren Anwendungs-Schichten so neunmalklug-studiert als "Businesslogic" bezeichnen (boh, charly!).
Also keine gute Idee, diesen entscheidenden Code irgendwo behind zu verstecken.

Also lege ich gleich einen Ordner DataStuff an, und darein kommt mein Dataset.
Und dann lege ich selber eine Partiale Klasse an, etwa MyDataset.logic.vb - die dann erfreulicherweise nicht vom Dataset-Designer versteckt werden, sondern die sieht man im SolutionExplorer.
Und wenn die dann zuwachsen mit ihre vielen Tabellen und Sonderwünsche, dann teile ich das auf, da mag es dann je Tabelle eine Datei geben, oder für eine besonders intensiv zu bespielende Datei eine Datei, und die anneren bleiben erstmal noch in MyDataset.logic.vb.

Aber alles Quatsch, sogar der gegebene Beispiel-Code.
Ohne einiges an Infrastruktur kann das Dataset seine Events doch nicht selbst verarbeiten. Weil die EventVerarbeitung muss man ja abschalten, wenn das Dataset befüllt wird.
Ja, tut mir leid - die Infrastruktur, die ich dafür zusammengebastelt hab ist mächtig gewaltig komplex.
Daher hänge ich einfach mal ein Sample an.
Solange du nicht in die Helpers-Projekte guckst, ist alles super-einfach, und gut strukturiert.
Beachte auch, dass bereits Default-Werte eingerichtet sind, und dass die DGVs bereits ein "Theme" haben, was viel besser aussieht als ihr Default.