Suchergebnisse

Suchergebnisse 1-11 von insgesamt 11.

  • Benutzer-Avatarbild

    sonst sieht er so aus:VB.NET-Quellcode (14 Zeilen)Allerdings das ohne die Setter-Variable explizit zu deklarieren ist glaub auch gültig - dann wird sie intern mit dem Namen "value" generiert. Für deine Exception würde ich mal nachdenken, ob das was mit Threading zu tun haben könnte.

  • Benutzer-Avatarbild

    Zitat von sonne75: „weil es ja so selten auftritt... “Ja, das ist typisch für die gemeinsten Fehler, die Threading verursacht, man nennts glaub auch die Race-Condition: Fast immer gehts gut, wenn mehrere Threads auf einer Auflistung rumorgeln, nur manchmal wenn grad superblöd das Dgv die Tabellenwerte abruft, und genau da fügt der annere was dazwischen, und das löst nu grad ganz unglücklich die neu-alloziierung der DataTable aus, weil die sich vergrößern muss... sodass das Dgv also Daten aus ein…

  • Benutzer-Avatarbild

    Zitat von sonne75: „Wie mache ich denn die Schreibroutinen threadsicher?“letztlich immer mit Control.BeginInvoke. Was anners gibts nicht. Auch Synclock und Konsorten nützen nix, einzig Invoking transferiert den Vorgang in den Gui-Thread. Und das ist sehr nervig, weil das ist sehr teuer. Also sieht man zu, dass man c.BeginInvoke nicht zu oft aufruft, also bei MassenOperationen nicht jeden Piss transferieren, sondern immer gleich große Datenpakete schnüren und transferieren. Was das für eine ständ…

  • Benutzer-Avatarbild

    Wenn eine BindingSource per Databinding Werte aus der DataTable abruft - da ist mir derzeit keine Möglichkeit bekannt - einen Synclock-Fuß dazwischenzukriegen. Aber ich guck gleich mal nach, ob DataTable oder Dataset ein SynchronisizingObjekt anbietet, und ob man damit tatsächlich auch Databinding threadsicher kriegt.

  • Benutzer-Avatarbild

    Wo steht das? Also ich kann mir das nicht vorstellen, dass ein Lesen ungesperrt gehen soll. Etwa das Lesen ruft Count ab, aber dann haut der Schreibe-Thread dazwischen, und löscht paar Zeilen? Und Anfügen ist eiglich auch nicht besser - kann mir schon vorstellen, dass da ein Index beschädigt wird, wenner zu beginn des Lesens 100 Elemente Indiziert, und am Ende auf einmal 120. btw - was meinst du mit "Gui blocken"?

  • Benutzer-Avatarbild

    naja - sobald ein DGV auffm Form ist, oder auch nur eine BindingSource, werden Daten vonne DataTable abgerufen. Eine Möglichkeit, das Gui zu blocken fund ich mal mit BindingSource.RaiseListchangedEvent=False, weil glaub DataSource-Databinding fußt ganzngar auffm ListChanged-Event. Aber sicher bin ich nicht, ob das wirklich ausreicht.

  • Benutzer-Avatarbild

    wie gesagt: mein Vorschlag suspendiert die Lese-Zugriffe via Databinding. Anschließend muss man sogar explizit bs.ResetBindings aufrufen, wenn man die geänderte Tabelle angugge will.

  • Benutzer-Avatarbild

    ach so, ja ich dachte, weil die Exception nur beim Initialisieren... Aber ist ja glaub falsch gedacht. Wie gesagt: Ich denke nicht, dass gute Idee ist, wenn der NebenThread ohne weitere Vorkehrungen Daten ins Dataset einfügt. Das muss man Invoken, oder mit ConcurrentQueue, oder mit RaiseListChanged.False oder was auch immer. Einer gebundenen DataTable was zufügen bedeutet letztendlich DGV.Rows.Add(wasAuchImmer). Und wenn du das direkt machst, ohne Databinding, hast du die CrossThread-Exception. …

  • Benutzer-Avatarbild

    noch einmal: Der NebenThread darf nicht ins Dataset schreiben, solange wie auch immer ein Databinding besteht. Das ist alles. Je länger ich drüber hirne, desto mehr Möglichkeiten fallen mir ein, jede mit Vor- und Nachteilen. Aber das wesentliche ist: NebenThread - nicht in ein gebundenes Dataset schreiben Wie du das bewerkstelligst ist egal. Der Ansatz mitte ConcurrentQueue ist, die Daten im Nebenthread nicht ins Dataset zu schreiben (hab ich das schon erwähnt? ), sondern erst in dieser Queue zu…

  • Benutzer-Avatarbild

    Warum ich das sage: Weil eine Zuweisung an ein gebundenes Objekt mit Sicherheit einen Schreibzugriff auf das angebundene Control nach sich zieht - das ist Databinding. Und Schreibzugriffe auf Controls aus einem NebenThread heraus sind nicht zulässig - das ist nicht stabil. Zitat von sonne75: „einfach das Falsche angezeigt (bzw. nicht aktualisiert)“Du beschreibst ja selbst ein höchst verdächtiges Fehlverhalten - sieht doch sehr nach Instabilität aus, odr? ResetBindings ist übrigens auch teuer - d…

  • Benutzer-Avatarbild

    muss man testen, kann mir aber vorstellen, das ist sehr zackig. Beim mergen werden die Rows anhand ihrer Primkeys verglichen: Findet sich eine Übereinstimmung, so werden die Spaltenwerte der Merge-Quell-Row in die ZielRow übertragen - die ZielRow löst dann eine Binding-Aktualisierung aus. Findet sich keine Übereinstimmung, so wird eine Komplett-Kopie der QuellRow in der Ziel-Tabelle geadded - auch hier erfolgt eine Binding-Aktualisierung. Alle anneren Rows bleiben unangetastet, und lösen auch ke…