Fehlerbehebung durch Option Strict so gut wie fertig

Wie meinste aus dem Kontext gerissen? Der Zusammenhang passt IMO. Du sagtes doch da wäre Option Strict Off noch zu bevorzugen, auch das man dann auch nicht casten muss. Ich sage darauf, ich finde das nicht so und auch warum.

Für mich war jedenfalls nicht erkennbar, das dies in irgendeiner Form rein auf die Cell-Value bezogen war, ehrlich gesagt, ich versuche das gerade immer noch zu verstehen. Ich les das morgen noch mal durch.

Moin moin

Ich frage mich, warum das Option Strict nicht standardmäßig ON ist?

Als ich vor 2 Jahren begann mit VB.net zu arbeiten hatte ich davon Null Ahnung.
Nur weil einige hier, mir immer wieder sagten Option Strict ON habe ich so einiges besser verstanden, vor allem die vielen Fehler die sich immer wieder einschlichen, wenn ich zum Beispiel versuchte Datentypen wild zu mischen usw.
Wenn ich heute etwas beginne, sei es auch nur ein Übungsproject schaue ich als ersten auf Option Strict ON und das dass alte VisualBasic entfernt ist!

@ErfinderDesRades

Also ich muss zugeben, dass ich mit dem DataBoundItem nicht zurechtkommen. Ich je mehr ich lese, umso weniger verstehe ich.
Auch die VBNet-Hilfe ist da nicht wirklich hilfreich.
Ich werde mir noch einmal deine Tutorial in Ruhe ansehen. Vielleicht kommt mir dann die Erleuchtung. Vielleicht finde ich auch auf Youtube ein paar hilfreiche Videos.
Ich kann nur sagen, dass so wie ich es bisher gemacht habe, ich nie Probleme hatte.

Gruß Achilleus

Was ist denn konkret unklar? DataBoundItem gibt untypisiert das Etwas zurück, welches in der vorgegebenen DGV-Zeile angezeigt wird. Hätte man im DGV eine List(Of MeineFahrzeugdatenklasse) angezeigt, würde in DataBoundItem also die im DGV selektierte MeineFahrzeugdatenklasseninstanz stecken und man käme über DirectCast(row.DataBoundItem, MeineFahrzeugdatenklasse) wieder an die MeineFahrzeugdatenklassen-Instanz. Hätte man zwischen der Datenklassenliste und dem DGV eine BindingSource, käme man über BindingSource.Current auch an das untypisierte Ding, genauso wie mit row.DataBoundItem. Wenn aber eine tDS-DataTable in dem DGV dargestellt wird, bekommt man ein DataRowView, dessen Row-Property ebenfalls zu dem untypisierten Ding führt. Ein Cast in den Soll-Typ (MeineFahrzeugdatenklasse oder eben die tDS-DataTable-Zeile) muss aber immer sein. Es sein denn, man benutzt meine typisierte BindingSource.

Und das ist das Problem. Ich lade mir doch keine Klassen in ein Datagridview, sondern Access-Tabellen. Also dann stellt sich mir doch die Frage, warum soll ich die DataBoundItem verwenden, wenn es bei mir immer nur "Einzelwerte" gibt. Wenn ich Daten ändern will, dann nehme ich die Datarow und die SQL-Commands.

Wenn sich die Spalten im Datagridview häufig ändern sollten, weil in der Access-Tabelle neue Werte hinzukommen, dann arbeite ich eben mit ​Enum-Anweisungen.

Aber wahrscheinlich habe ich das einfach nicht begriffen.

Öhm. Der TE nutzt (wohl ein (typisiertes?) DataSet mit) DataTables. Und Du packst die Access-Rohdaten ins DGV direkt? Ohne tDS, DataTable, ORM oder irgendwas anderes? Dann reden wir wohl aneinander insofern vorbei, denn: was hat das dann noch mit OOP (objektorientierter Programmierung) zu tun? Oder setz ich das voraus, obwohl das nicht ein Grundprinzip Deiner Programmierung ist?
Klingt jetzt vielleicht etwas harsch, soll es aber nicht. Also kurz: Hast Du nur Rohdaten im DGV oder werden da auch irgendwann Objekte draus?

Natürlich habe ich Datatables, Datasources, OleDBConnection usw. und alles andere.

DTF schrieb:

ich versuche das gerade immer noch zu verstehen

Dass dein Zitat von mir aus dem Kontext gerissen ist, ist daran erkenntlich das weniger Inhalt als im Original vorliegt. Da gibts schonmal nicht viel Probleme beim Verstehen.
Da steht "bevorzugen" aber nicht was gegenüber (das wird in meinem Post durch den Kontext allerdings klar). Du stellst dann anschließend jedoch On und Off gegenüber.
Dadurch würde jeder der nur Post 18 liest denken, ich hätte irgendwo geschrieben Off>On, was faktisch nicht gegeben ist.

@Achilleus: Wie DTF bereits in Post#16 schrieb, bist Du dann mit Deinem Code an die Darstellung im GUI gebunden. Du schreibst ja jetzt z.B. in Dein Code (zumindest ist das Dein Vorschlag in Post#11):

Update mir das Element mit einer bestimmten ID. Die ID findest Du in der DGV-Spalte 9 in der aktuellen Zeile.

Wenn Du dann aber im Verlauf der Entwicklung feststellst, dass eine Datenspalte noch hinzukommt (Kundenanforderung) oder wegfällt (weil die entsprechenden Daten für das Programm nicht mehr benötigt werden) oder weil Kunde oder Du die Spaltenreihenfolge anders haben will(st), dann musst Du Deinen Code anpassen und alle Stellen raussuchen und abändern, in denen Du auf eine explizite DGV-Spalte zugreifen musst.
Wenn Du aber row.DataBoundItem oder BindingSource.Current hernimmst und das in Deine (hoffentlich typisierte) DataRow castest, kannst Du einfach sagen:

Update mir das Element mit einer bestimmten ID. Die ID findest Du im ausgewählten Element.

Also kein GUI-Bezug mehr, sondern Datenbezug. Und schon ist es vollkommen wurscht, wo die ID im DGV steht oder ob überhaupt irgendeine ID im DGV steht, denn Du bist noch nicht mal mehr darauf angewiesen, dass die benötigten Daten explizit angezeigt werden. Sie müssen nur im Objekt (DataRow) sein.

Hallo @VaporiZed,

ich bin ja lernwillig.
Wie verwende ich denn die row.DataBoundItem, wenn ich nur eine normale Tabelle in einem DGV darstelle?
Alle Beispiele reden immer von Klassen, die habe ich aber doch gar nicht oder ich begreife das System nicht.

Beispiel:



Mein konkrete Frage ist nun, wie kann ich in meinem Beispiel "FrmAuswahlFinanzamt_Load" row.DataBoundItem sinnvoll verwenden?
In meinem Beispiel verwende ich ja sValue1 = Convert.ToInt32(DGVFinanzamt.Rows(i).Cells(0).Value), was nur suboptimal ist oder?

PS: Gibt es eigentlich eine elegante Methode einen Zellwert in einem Datagridview zu suchen und diesen dann zu markieren? Ich mache das ja im Augenblick mit For i to Next.

Vielen Dank im Voraus.

Gruß Achilleus

Es ist in Post 24 ja aufgemalt.
DataBoundItem kann alle möglichen Typen beinhalten. Den musst du rausfinden und dann casten.

Achilleus schrieb:

Ich mache das ja im Augenblick mit For i to Next

Hängt auch davon ab ob oder wie du in deiner Quelle suchen kannst. Z.B. Enumerable.First()

vielleicht so: Problem ist, dass ich nicht weiss, ob du ein typDataset hast, und wie der genaue Datentyp heisst. Dazu müsste man das Dataset mal im DatasetDesigner sehen.
Daher ist der Ausdruck myDataset.tblFinanzämterRow mit erheblicher Unsicherheit behaftet.

Ansonsten guck dir meine Tuts an, die ohne Datenbank.
Um eine Dgv-Zeile auszuwählen braucht man keine Datenbank.
Allerdings zeigen meine Tuts nur sowas ähnliches: etwa, wie auf einen Datensatz gefiltert wird, oder wie anhand eines Datensatzes aus anderen Datensätzen was berechnet wird und so Kram.
Und ich verwende lieber BindingSource.Current, oder BindingSource(index) statt dgv.Rows(index).DataboundItem.
Aber beides ist sehr ähnlich, und der hier gezeigte DoppelCast, um die typDataRow zu erhalten ist derselbe.

Ich verwende auch kein DataView, und dgv.CurrentCell setze ich auch nicht.
Ich setze lieber BindingSource.CurrentPosition - das gebundene dgv springt dann automatisch dahin.
Du siehst: Mein Code würde das Dgv an keiner STelle auch nur erwähnen.
Aber das geht natürlich nur, wenn man die Anwendung auch dementsprechend aufbaut: nämlich dass bereits im FormDesigner das Dgv an eine BindingSource gebunden wird, welche wiederum ans typDataset gebunden ist.

Hallo @ErfinderDesRades,

vielen Dank für deinen Input. Ich werde mir noch einmal in aller Ruhe deine DB-Tuts anschauen.

Du hast mich zumindest auf die richtige Spur für meine Zeilenauswahl im DatagridView gebracht.

Zwei Methoden habe ich gefunden, um den Index zu einer Zeile zu finden:

1. Variante: Suche im Dataview



2. Variante: Suche in BindingSource()



Damit erspare ich mir das Durchlaufen des DGV. Ich verwende jetzt die zweite Variante, da diese kürzer ist und eine Sortierung entfällt. Die Daten werden im DGV ja auch genauso angezeigt wie sie sich in der BindingSource befinfen.

Es gibt also noch viel zu lernen für mich.

Gruß Achilleus

PS: Änderung wg. Rechtschreibfehler.