Welches Ereignis zum Laden der Daten und Speciehrn verwenden?

  • VB.NET

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von VB1963.

    Welches Ereignis zum Laden der Daten und Speciehrn verwenden?

    Ich bin ein wenig verwirrt. Ich habe mir zum Testen (comeback zu VB nach vielen Jahren) ein Formular mit Datagridview gebaut. Das Handling, also Aufbau der Connection, füllen und speichern soll komplett über Code gelöst werden.

    Ich kann das Datagridview mit Daten füllen, wenn ich das über ein Button-Ereignis mache. Ich kann auch Datensatz Änderungen speichern, wenn ich einen Button verwende. Nun möchte ja keiner ständig Buttons drücken, also wollte ich gerne die Ereignisse Form_Load and Form_FormClosing verwenden, liegt ja nahe. Und nun geht es nicht mehr, die geänderten Daten werden weder geladen noch zurückgespeichert. Die Zeitpunkte scheinen falsch zu sein.

    Anm.: Ich habe einen anderen Test gemacht und die Connection, Adapter etc. über die VS GUI erzeugt, im Prinzip dasselbe, die Daten werden hier zwar geladen, aber nicht zurückgeschrieben, der Designer verwendet dieselben Ereignisse, die ich auch ausgesucht hatte. ****War nur zum Testen wie VS das selber machenwürde, ich dachte, ich könnte es dann adaptieren, aber nichts da.

    Welches sind die korrekten Ereignisse oder fehlt mir noch irgendwas?

    Hier,nur informativ, weil die Routinen ja grundsätzlich funktionieren, mein Code zum Speichern:


    Quellcode

    1. Try
    2. bindingSource1.EndEdit()
    3. Me.adapter.Update(CType(bindingSource1.DataSource, DataTable))
    4. ceconn.Close()
    5. Catch ex As Exception
    6. MessageBox.Show(ex.Message)
    7. System.Threading.Thread.CurrentThread.Abort()
    8. End Try


    Ich benutze Objekte aus System.Data.SqlServerCe. Danke im voraus (darf man das hier schreiben?)
    Willkommen im Forum. :thumbup:

    piasophie schrieb:

    Form_Load
    Ich denke, hier liegt das Problem.
    Es ist bekannt, dass manche Exceptions in der Form_Load verschluckt werden, d.h., die Form_Load wird abgebrochen und die Form wird ohne Meldung weiter gestartet.
    Wenn Dein Code in einer Button_Click funktioniert, rufe diese Button_Click-Prozedur aus der Form_Shown auf.
    Um sicherzustellen, dass Deine Form_Load funktioniert, setze da einen Haltepunkt rein und steppe sie zeilenweise durch. Gugst Du hier.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Guten Morgen

    Wahrscheinlich wurde der Zugriff auf die Datenbank oder auf ein entsprechende Objekt in dem Moment (also in der Form_Load) noch gar nicht möglich. Der Zugriff muss sichergestellt sein.

    Mit

    VB.NET-Quellcode

    1. Me.[ButtonName].PerformClick()

    kann die Funktion eines Buttons ausgeführt werden.

    Freundliche Grüsse

    exc-jdbi

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „exc-jdbi“ ()

    Ich habe jetzt meinen Quellcode in das Ereignis Form_Shown kopiert, das klappt nun. Vielen Dank dafür
    Als Test hatte ich gestern schon mal einfach nur eine Messagebox in Form_Load aufgerufen, da passiert gar nichts.

    Jetzt fehlt mir noch das Speichern. Hier ist es dasselbe, wenn ich eine Messagebox ins Ereignis Form1_FormClosing setze, wird diese auch nicht ausgeführt. Gibt es auch hier ein besseres Ereignis? Ich habe schon Unload gesteset, geht auch nicht.

    @ErfinderDesRades Warum ist try...catch ein Problem? Ich bin daran aus C und Java so gewöhnt. Gibt es bei VB on error ...goto, wie in VBA oder was wäre hier eine gute Wahl.?

    Danke an alle!
    Deine Nachfragen ärgert mich bischen, weil ich hab dir doch extra einen Link herausgesucht, der das umfassend umfassend diskutiert. Wenn du das nun noch weiter zu diskutieren benötigst, dann bitte mit Bezug auf eines der dort angeführten Argumente, und inwiefern du diesem widersprechen tätest.
    Oder bring ein neues Argument, was im Link zu erwähnen versäumt wurde.

    Ansonsten nur kurz: Nur weil man etwas gewöhnt ist, ist es noch lange nicht gut. Insbes. bei schlechten Gewohnheiten ist das genaue Gegenteil der Fall.
    Und das TryCatch-Problem ist tatsächlich meist ein Gewohnheits-Problem - deswegen muss ich im verlinkten Tut ja auch so immens rumackern, unds bleiben immer noch genügend Leute übrig, die's einfach nicht kapieren (wollen / können).

    piasophie schrieb:

    da passiert gar nichts
    was bedeutet, dass er vorher rausgeflogen ist.
    Also: Lerne zu debuggen, nutze den Link aus Post #3.
    Du solltest Dir eh angewöhnen, jeden geschriebenen Code zu testen, da kann man gar nicht früh genug mit anfangen.

    ein Kollege schrieb:

    Jede nicht getestete Zeile Code ist falsch!

    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Also debuggen kann ich, bei 20 Jahren Programmiererfahrung, also bitte. Hochmut kommt vor dem Fall.

    Die Ereignisse waren das Problem. Laden bei Form_Shown und Speciehrn bei Form_Closed.

    try...catch ist eben Stae of the Art bei C und Java, ich hatte mir eine Antwort erhofft und nicht immer dieses "hochgehobener Zeigefinger" ist wirklich nicht zielführend. Ok also on error, ist letztendlich auch übersichtlicher.

    piasophie schrieb:

    Also debuggen kann ich, bei 20 Jahren Programmiererfahrung, also bitte. Hochmut kommt vor dem Fall.
    Eigentlich möchte ich deeskalation bewirken, doch dass du dich selbst mit dieser Aussage abschießt, ist dir bewusst oder?

    piasophie schrieb:

    try...catch ist eben Stae of the Art bei C und Java
    Ist es auch hier, doch try-catch neigt eben dazu das eigentliche Problem zu verstecken. Alles was @ErfinderDesRades sagen will ist folgendes:
    Programmiere so weit es geht ohne Try-Catch. Und wenn du es brauchst, schließe damit so wenig Code wie möglich ein. Denn Fehler zu entdecken, ist ohne Try-Catch wesentlich einfacher als mit. Wenn man um jeden Code Try-Catch rumbastelt stellt sich auch die generelle Frage, ist der Code getestet? Funktioniert dieser Code überhaupt? Warum misstraut der ursprüngliche Entwickler diesem Code-Abschnitt?