EventHandler DataRow - nach dem Einfügen...

  • VB.NET

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    EventHandler DataRow - nach dem Einfügen...

    Hallo in die Runde

    Ist-Situtation

    Anwendung mit DataSet:
    - Mastertabelle (Beschreibt ein Objekt)
    Erfssung der Objekte über ein DataGridView oder auch gebundene Textfelder im Formular.

    - Detailtabelle (Aufgaben und -dauer zum Objekt)
    Eine bestimmte Anzahl an Aufgaben ist für alle Objekte der Mastertabelle gleich, weitere müssen individuell angelegt werden.
    Die für alle Objekte gleichen Aufgaben möchte ich per Programmierung der Detailtabelle zufügen.
    Die individuellen Aufgaben dann später über manuelle Eingabe in einem DataGridView.

    Programmtechnisch funktioniert das auch alles - per Click auf Buttons.
    Masterdatensatz im DGV angelegt, ausgewählt und Button 'Details erzeugen' angelickt.

    Problemstellung
    Ich möchte, dass die Detaildaten automatisch erzeugt werden, nachdem der Masterdatensatz in die DataTable eingefügt wurde.

    Fragestellung
    Welches Ereignis kann dazu verwendet werden?
    Die neue DataRow muss in der Datentabelle aufgenommen sein, bevor der Detaildatensatz erzeugt wird.

    DataGridView und BindingSource
    bieteten (?) kein Ereignis, welches anzeigt, dass eine neue DataRow der DataTable hinzugefügt wurde.
    Beide bieten lediglich ein Ereignis, welches anzeigt, dass 'begonnen' wurde, eine neue Row anzulegen; nicht aber, dass diese Row dann auch tatsächlich der Tabelle hinzugefügt wurde.


    Bin vermutlich heute morgen schlecht aufgestanden, sehe den Wald vor lauter Bäumen nicht und google mittlerweile seit fast 4 Stunden an dem Problem.
    Für eure Hilfe schon einmal Danke. Ein einfacher Link: schau mal dort, oder google mal nach 'dem' Stichwort wäre hilfreich.

    Gruß
    Andreas
    Das Stichwort 'DataTable.RowChanged - Event, mit e.Action = System.Data.DataRowAction.Add' war hilfreich... Danke!!!

    Habe nur nach Ereignissen von Objekten (DataGridView, BindingSource) geschaut, die mir VS in der grafischen Designeroberfläche zur Verfügung stellt. Das DataTable-Objekt taucht dort aber nun einmal nicht auf. Einen AddHandler für das DataTable-Objekt im Code zu setzen - schlichtweg nicht dran gedacht; dabei habe ich es in der Vergangenheit schon öfters so gemacht. Aber, ein 'Hobbyprogrammierer' vergisst schon mal :)

    VB.NET-Quellcode

    1. Private Sub frmTimePlan_Load(sender As Object, e As EventArgs) Handles MyBase.Load
    2. DsDaten.ReadXml("DSO_Daten.xml")
    3. AddHandler DsDaten.dtReferenzE.RowChanged, AddressOf dtReferenzE_RowChanged
    4. End Sub
    5. Private Sub dtReferenzE_RowChanged(sender As Object, e As DataRowChangeEventArgs)
    6. If e.Action = DataRowAction.Add Then
    7. ' ----- Hier erstelle ich nun die Datensätze der Detailtabelle
    8. End If
    9. End Sub


    Was die richtige Nutzung von VS angeht... Ich versuche es ja.
    Aber lernen bedingt manchmal auch einen Lehrer. Und 'Google' ist nicht nur nicht meine Mami, eben aber auch kein Lehrer.
    Wie mir der Link auf das YouTube-Video weiterhelfen soll, habe ich nicht so richtig verstanden.

    Hoffe, dass mein Lösungsansatz so in die richtige Richtung geht.
    Danke nochmals

    Andreas

    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?
    Doch, soweit klar. In der Regel arbeite ich mit der Online-Dokumentation von microsoft zum VS und komme gut damit klar.
    Nur, wenn man ein Problem hat, und kann es nicht in 'Worte' fassen - bzw. weiß nicht, unter welchem Thema man nachlesen muss - hilft auch die beste Dokumentation nicht, dann hilft nur fragen.

    Habe heute morgen vermutlich (fast) sämtliche Ereignisse des DGV und der BindingSource 'gelesen' - beide 'arbeiten' mit der DataTable. 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. Das findet man nicht mal eben in einer Dokumentation; dafür braucht man jemanden, der es weiß - z.B. einen 'Lehrer'.

    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.
    Moin EDR...
    Sorry, dass ich erst jetzt wieder etwas von mir hören lassen - wenig Zeit zurzeit.

    Habe jetzt aber gerade den von dir erwähnten Dataset-Codebehind aufgerufen. Bräuchte dazu aber mal ein Beispiel wie man den an dieser Stelle nutzt - für den Einstieg nicht zu komplex und leicht verständlich.

    Gruß
    Andreas

    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:

    VB.NET-Quellcode

    1. Imports System.Data
    2. Partial Class DsDaten
    3. Partial Public Class dtReferenzEDataTable
    4. Private Sub dtReferenzEDataTable_dtReferenzERowChanged(sender As Object, e As dtReferenzERowChangeEvent) Handles Me.dtReferenzERowChanged
    5. If e.Action = DataRowAction.Add Then
    6. ' ----- Hier erstelle ich nun die Datensätze der Detailtabelle
    7. End If
    8. End Sub
    9. End Class
    10. End Class
    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.
    Dateien
    • ParentChild00.zip

      (226,16 kB, 67 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „ErfinderDesRades“ ()