DataGridView neu füllen aus Array

  • VB.NET

Es gibt 24 Antworten in diesem Thema. Der letzte Beitrag () ist von Lightsource.

    DataGridView neu füllen aus Array

    Ich habe eine DataGridView an ein Array gebunden ( DGV.DataSource= array)

    Wie ist nun die richtige Vorgehensweise, wenn ich die Daten aus dem Array neu
    in das View übergeben will. Bis jetzt habe ich vorher die DataSource= Nothing gesetzt.
    Leider komme ich dann bei Anklicken einer Zelle in ein nicht abfangbares seltsames
    Fehlerszenario.

    ( Zur Erklärung: Die Daten stammen von einem Handscanner der Barcodetext in
    eine Textbox überträgt. Diesen Text nehme ich und splitte ihn an den Zeilenumbrüchen.
    Das Ergebnis ist ja ein Array. Dieses habe ich dann direkt an das DGV gebunden )





    ...

    Abend,

    ich weiß nicht genau, ob meine Antwort zu deiner Frage passt (vor allem, da ich selbst Antworten wie "mach es doch anders" nicht leiden kann).
    Aber ich würde eher DG.ItemsSource nehmen. Wenn du dem Itemssource erst nothing zuweist und anschliessend wieder das (neue) Array, dann werden die Daten aktualisiert angezeigt.

    Welchen Fehler bekommst du denn genau? Hast du ein Event erstellt, mit welchem du etwas machen wolltest?

    VG

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „MatthiasB“ ()

    Der Fehler tritt an meinem Arbeitsplatzrechner auf. Dort habe ich auch die genaue Fehlermeldung.
    Es geht darum, dass sich der Compiler über ein Index=-1 beschwert.
    Die Fehlermeldung kommt, ohne dass eine Zeile im Code markiert wäre. Ich weiß also
    nicht genau wo der Fehler im Code auftritt.

    Nachdem ich im Internet nach der Fehlermeldung gesucht hatte, fand ich einige Leute,
    die behaupteten, es könne an der Nothing-Zuweisung des DataGridView liegen.

    Wenn ich aber keine Nothing Zuweisung an das DataSource übergebe, werden meine
    Daten erst gar nicht in das Grid geladen.

    ItemsSource finde ich übrigens nicht bei DataGridView

    SystemUnknown, du hast mich drauf gebracht, dass ich in meinem ersten Beitrag etwas Falsches
    geschrieben hatte. Sorry, hab ich euch auf eine falsche Spur geführt. ;(

    Nein, ich habe tatsächlich das Array erst an eine Klasse übergeben, die ich dann
    an das Grid gebunden habe.

    Ich schaue mir die Tipps aber trotzdem gerne an. :)

    ich würde ein DGV nicht an ein Array binden.
    Tatsächlich würde ich es unbedingt an eine typisierte DataTable binden, und nix anneres, denn das ist die dafür vorgesehene Datenstruktur, und ist enorm mächtig, und genießt ebenso enorme Unterstützung bei der Arbeit im FormDesigner.

    gugge Daten laden, speichern, verarbeiten, wenndemagst

    Mache ich normalerweise auch.
    Ich möchte die Daten aber nur Anzeigen. Maximal vielleicht Zeilen verschieben...

    Wie schon gesagt hatte ich tatsächlich an eine Klasse gebunden.
    Das klappt ja auch soweit.

    Vielleicht hast du ja gelesen wo meine Daten her kommen.
    Ich muss erst eine Textbox verarbeiten und die erhaltenen Daten
    in einer bestimmten Reihenfolge im Grid darstellen.
    Da war es für mich der kürzeste Weg, den ich verwendet habe.
    Ob ein DataTable da wirklich Vorteile haben würde weiß ich nicht.

    Lightsource schrieb:

    Ob ein DataTable da wirklich Vorteile haben würde weiß ich nicht.
    Das halte ich allerdings für sehr wahrscheinlich (kann mich natürlich auch irren)

    Wenn du dir die Beherrschung der Dataset-Technologie einmal angeeignet hast, wirst du feststellen, dasses in fast jedem Fall ein kürzerer, sicherer und v.a. leistungsfähigerer Weg ist, als der Weg über selbstgebastelte Daten-Klassen.

    ErfinderDesRades schrieb:

    ich würde ein DGV nicht an ein Array binden.

    Ich schon, insbesondere dann wenn hier nur Ausgabe erfolgen soll: im Widerspruch zu EDR ist es imho meistens (nicht immer) ziemlicher Dummfug den Data Access Layer (DAL) direkt an den Presentation Layer zu binden.

    Genauer gesagt würde ich das DGV zur Design Time an einen Typ (=Klasse) binden, und während der Runtime an ein entsprechendes IEmumerable(of T), z.B. Array, List.

    ErfinderDesRades schrieb:

    dasses in fast jedem Fall ein kürzerer, sicherer und v.a. leistungsfähigerer Weg ist, als der Weg über selbstgebastelte Daten-Klassen.

    Blubb ...

    Ich höre euch jetzt gerne beim Streiten zu, da lerne ich bestimmt noch Einiges. :thumbsup:

    Aber zurück zum Thema.
    Das auf Nothing Setzen der DataSource Eigenschaft scheint ja gängige Praxis zu sein.
    Aber irgendwie kommt mir das etwas suspekt vor, die Datasource-Verbindung einfach
    so abzuschießen. Ich hatte gehofft, dass es da einen etwas humaneren Weg gäbe, der
    dann auch in der Lage ist, die erhaltene Fehlermeldung zu umgehen.

    Kangaroo schrieb:

    Genauer gesagt würde ich das DGV zur Design Time an einen Typ (=Klasse) binden, und während der Runtime an ein entsprechendes IEmumerable(of T), z.B. Array, List.
    das sieht zunächstmal natürlich ebenso hübsch aus, erfordert aber ungefähr gleichviel KnowHow wie die Geschichte mit typ. Datasets.
    Ist halt weniger leistungsfähig, zB was filtern angeht.
    Auch laufende Aktualisierung wird nicht unterstützt, denn in selbstgebastelten Datenklassen müsste INotifyPropertyChanged erst implementiert werden, damit das DGV auf Änderungen an den Daten auch reagieren kann.
    Das gehört aber zu den Anforderungen aus post#1:
    Wie ist nun die richtige Vorgehensweise, wenn ich die Daten aus dem Array neu
    in das View übergeben will.
    Ein an eine selbstgebastelte Klasse gebundenes DGV muß auf eine komplett neue Datasource gesetzt werden, was mehr oder weniger flackert.
    Hingegen bei einer DataTable hätte man die möglichkeit, Änderungen im Einzelnen an bestehende Datensätze vorzunehmen - was ühaupt nicht flackert.
    Aber vlt. reicht ja ersterer Ansatz für die Anforderungen, und die Daten kommen eh immer komplett neu heran.
    Dann habichda auch nix gegen zu sagen, ausser, dass man mit demselben Lern-Aufwand auch die leistungsfähigere Dataset-Technologie kennenlernen könnte.


    Lightsource schrieb:

    Das auf Nothing Setzen der DataSource Eigenschaft scheint ja gängige Praxis zu sein.
    Watt :?: :?:

    Lightsource schrieb:

    Ich höre euch jetzt gerne beim Streiten zu, da lerne ich bestimmt noch Einiges.

    Ich streite als allgemein friedfertiger Mensch grundsätzlich nie :rolleyes:

    Problem beim Binding eines Arrays an Ein DGV ist, dass das DGV leider nie mitbekommt wenn sich die Werte des zugrundeliegenden Array ändern.

    Als Ausweg kannst Du der DGV.Datasource das Array wieder neu zuweisen.

    Besser ist allerdings , statt eines Arrays eine BindingList(of T) zu verwenden: diese funktioniert prinzipiell wie eine normale List(of T), hat allerdings den Vorteil Events (i.e. INotifyCollectionChanged) zu besitzen, die eine BindingSource benachrichtigen wenn sich Elemente geändert haben.

    Sprich: verwendest Du eine BindingList, so 'updated' sich das DGV automatisch.

    Ist halt weniger leistungsfähig, zB was filtern angeht.

    Dafür arbeite ich aber mit normalen Business Objects statt mit einer blödsinnigen DB-Table, die nur so tut als sei sie ein typsicheres Business Object.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Kangaroo“ ()

    Kangaroo schrieb:

    Sprich: verwendest Du eine BindingList, so 'updated' sich das DGV automatisch.
    Aber nur unvollständig.
    Änderst du eine Property eines der Items, die inne Bindinglist drin sind, kriegt das DGV das nicht mit.


    Dafür arbeite ich aber mit normalen Business Objects statt mit einer blödsinnigen DB-Table, die nur so tut als sei sie ein typsicheres Business Object.
    Damit ists natürlich wieder ein sehr tragfähiges Konzept.

    Nur mit gescheite Business-Objects zu implementieren, ist der TE glaub wirklich zunächstmal überfordert.

    ErfinderDesRades schrieb:

    Änderst du eine Property eines der Items, die inne Bindinglist drin sind, kriegt das DGV das nicht mit.

    I know. Gleiches Problem beim Sort in der Basisklasse BindingList. Aber liegt ein solches Szenario vor ? Und wenn dann schafft INotifyPropertyChanged Abhilfe , wie Du weisst ...

    Und der grosse Nachteil von Deinen so übereifrig proklamierten 'typsicheren Datatables' ist halt, dass sie .. tja .. nur gepushte, aufgeblähte, typunsichere DB-Table-Imitationen sind. Und wie war das mit dem Binden des DAL an den Presentation Layer nochmal ?

    ErfinderDesRades schrieb:

    ausser, dass man mit demselben Lern-Aufwand auch die leistungsfähigere Dataset-Technologie kennenlernen könnte

    Blubb ...

    ErfinderDesRades schrieb:

    Nur mit gescheite Business-Objects zu implementieren, ist der TE glaub wirklich zunächstmal überfordert.

    Das finde ich gerade eben nicht, denn genau das war sein erster Ansatz. Warum ihn also unbedingt auf Dino-Technologie verweisen ?

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von „Kangaroo“ () aus folgendem Grund: Bin heut abend wohl formatiertechnisch überfordert

    Ok Ok.

    Nicht zu viel Information auf einmal! :D

    Nur mit gescheite Business-Objects zu implementieren, ist der TE glaub wirklich zunächstmal überfordert.

    Uff



    Die Sache mit der BindingList interessiert mich jetzt aber. Das werde ich mal testen.


    Wie Oben schon erwähnt möchte ich gerne die Reihenfolge der Datenzeilen nach Belieben ändern können.
    Also eigentlich keine Sortierung, sondern nur nach persönlichen Vorzügen anordnen.
    Ist das dann möglich?

    Ja

    Aber bring doch erstmal ühaupt deine Daten zur Ansicht.

    Kangaroo schrieb:

    Genauer gesagt würde ich das DGV zur Design Time an einen Typ (=Klasse) binden
    Das wird die erste Hürde sein, denn der WinForm-Designer unterstützt nicht so richtig ohne weiteres das Binden zur DesignZeit an einen Typ.

    Da müssteste dir vom Datenfenster erstmal eine DataSource generieren, und im entsprechenden Assistenten den Typ "Object" wählen statt "Datenbank".

    gugge vlt. Objekt-Databinding

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

    ErfinderDesRades schrieb:

    Ja

    Aber bring doch erstmal ühaupt deine Daten zur Ansicht.


    Hat ja bisher auch schon geklappt. Aber als ich eine Zelle angeklickt habe
    kam die Fehlermeldung, daher kam ja meine Frage...

    Vielleicht habt ihr ja auch noch zu einem anderen Punkt dieses Programmes
    eine Idee: ( Gehört eigentlich indirekt zu diesem Thread)
    Ich hatte ja schon geschrieben, dass ich Barcodes in ein Textfeld einlese.
    Diesen Text dann in ein Array splitte und damit die Klassenliste fülle, die
    ich an das DataGrid gebunden habe.

    Nun das Problem ist das Textfeld. Zum Starten des Scannens
    klickt man einen Button. Zum Beenden ebenfalls. Inzwischen sind
    die Barcodetexte in die Textbox eingelaufen. Da dies allerdings eine
    gewisse Zeit beansprucht, muss ich verhindern, dass der User zu früh
    auf Stoppen klickt. Auf der anderen Seite weiß ich aber auch nicht,
    wann die Textbox fertig gefüllt ist.

    Am Einfachsten wäre es, wenn ich die Daten direkt in das DataGridView
    bzw. ein Table fließen lassen könnte. Aber leider muss ich die
    gescannten Textzeilen erst zerpflücken und auf Plausibilität überprüfen.
    Es könnte ja shcließlich sein, dass der User ein falsches oder teilweise
    unleserliches Etikett eingelesen hat.



    ...

    Lightsource schrieb:

    kam die Fehlermeldung
    welche Fehlermeldung?

    Ich tippemal auf einen Datagridview-DataError. Der kommt als Messagebox.
    Du brauchst sie jetzt nicht abzuschreiben, denn Messageboxen kann man komplett mittels Strg-C in den Kopierspeicher übernehmen (und dann hier einpasten)

    Lightsource schrieb:

    daher kam ja meine Frage...

    Zu der hast Du wohl genügend kontroverse Kommentare :)

    Lightsource schrieb:

    Inzwischen sind die Barcodetexte in die Textbox eingelaufen

    Das überfordert mich jetzt: wir/ich wissen einfach zu wenig über Deine Anwendung um Dir zielgerichtet Antworten geben zu können.

    Grundsätzlich sind dafür Events gedacht, die Dir mitteilen wenn ein bestimmter Arbeitsschritt erreicht worden ist. So kann z.B. ein Event BarCodeRead dafür sorgen dass Deine Buttons oder Textboxes freigeschaltet werden. Genausowenig ist es gute praxis Deine Barcodes direkt in der Textbox zu speichern: eine Textbox ist in diesem Fall nur zum Anzeigen da.

    Kangaroo schrieb:

    Zu der hast Du wohl genügend kontroverse Kommentare

    Och - im Grunde sinds doch vorwiegend nur 2 Strategien, die empfohlen werden: fertigen Dino nehmen oder alles selber basteln.
    Und in einem Kern scheint mir gar Einigkeit zwischen uns Friede-Hähnen :whistling: vorzuliegen: Dasser sein DGV zur Designzeit binden soll.

    Ich halte es für recht wahrscheinlich, wenner dieses beherzigen täte, träte auch der eingangs erwähnte Fehler nicht auf.

Facebook
Telefonspende