Mehrere Kommas in Datagrid verhindern/sperren nur ein Komma zulassen

[pebbles]

Hallo

ich möchte verhindern, dass in einem DataGridView in einer Zelle nicht mehr wie ein Komma eingegeben werden kann.

Z.B. so etwas 22,,5,63

Mein Bisheriger Code sieht folgendermaßen aus:

Private Sub Dgv_EditingControlShowing(ByVal sender As Object, ByVal e As DataGridViewEditingControlShowingEventArgs)
Dim Tb As TextBox = CType(e.Control, TextBox)
RemoveHandler Tb.KeyPress, AddressOf Tb_KeyPress
AddHandler Tb.KeyPress, AddressOf Tb_KeyPress

End Sub

Private Sub Tb_KeyPress(ByVal sender As Object, ByVal e As KeyPressEventArgs)


If e.KeyChar <> vbBack Then
Select Case DGV_Listenansicht.CurrentCell.ColumnIndex
Case 1 'Eingabe Stück nur Zahlen
If Not Char.IsDigit(e.KeyChar) Then e.Handled = True
Case 3 'Eingabe Einzelpreis nur Zahlen, Komma und Zurücktaste
If Not (Char.IsDigit(e.KeyChar) Or e.KeyChar = Chr(44)) Then e.Handled = True
End Select
End If

End Sub


Allerdings kann ich hier beliebig viele Kommas eingeben und nach Return kommt eine riesen Fehlermeldung.

Danke für Eure Hilfe

[Ralf Jansen]

So wie du das vorhast ist das vermutlich nicht zielführend. Die ganze Logik zum prüfen da ranzuflanschen ist schwer. KeyPress hilft dir zum Beispiel nicht wenn ich den Wert per Copy&Paste in die Zelle schreiben würde. Dann gibt es kein KeyPress.

Gefühlt würde ich schauen das ich mir ein TextBox Derivat besorge das eine saubere Float Prüfung macht. Das Netz sollte voll sein mit entsprechenden Beispielen.
Und dann diese TextBox vom DataGridView benutzen lassen. Da helfen dann die CellBeginEdit/CellEndEdit Events des DataGridViews um diese andere TextBox zum richtigen Zeitpunkt zum editieren ein bzw. auszublenden.

Noch sauberer wäre es eine eigene DataGridViewColumn abzuleiten die gleich einen passenden Editor verwendet.

[fanderlf]

Die Frage ist doch schon warum das überhaupt der Editor machen muss? Kann man da nicht einfach eine Logik für die gebundenen Daten machen, die verhindert, dass in den an dem UI gebundenen Model zwei Kommas landen? Für mich sind UI Komponenten rein Darstellung und kein Platz an den Businesslogik gehört.

[pebbles]

Danke erst einmal für die Antworten, ich werde versuchen das Problem anders zu lösen.

[pebbles]

Hab auch schon eine andere Lösung Funktion gefunden, das Date-Error Ereignis.

[Ralf Jansen]

Die Frage ist doch schon warum das überhaupt der Editor machen muss? Kann man da nicht einfach eine Logik für die gebundenen Daten machen, die verhindert, dass in den an dem UI gebundenen Model zwei Kommas landen? Für mich sind UI Komponenten rein Darstellung und kein Platz an den Businesslogik gehört.

Möglicherweise eine sehr softwarephilosophische Betrachtung der Geschichte. Aber etwas das während ich tippe passiert ist keine Businesslogik sondern nur Logik der UI. Die Daten die da entstehen sind volatil und noch nicht Teil eines tatsächlich auf Businessregeln prüfbaren Konstrukts. Oder anders ausgedrückt während ich die UI bearbeite werden die meisten temporären Zustände der UI nach den Businessregeln ungültig sein. Das hier angesprochene Feld könnte zum Beispiel nur ein Komma enthalten. Das sollte gültig sein für die UI aber nicht für die Businesslogik. Der Feldinhalt wird erst nach einem bestimmten festzulegenden Zeitpunkt zu einem , dann hoffentlich gültiges Teil, der Daten und damit gegen Businessregeln sinnvoll prüfbar. Eine Formatprüfung ob ein string ein gültiges float format hat oder noch ergeben kann während der Eingabe ist also UI Logik und nie Businesslogik. Sollte man das so gemacht haben und nicht halbwegs getrennt haben würde ich für dieses System in Zukunft bei bestimmten Erweiterungen mit Problemen aus dieser Ecke rechnen.
Wie ich es auch gerne ausdrücke das hier ist ein reines Quality of Life Feature der UI unabhängig von der Businesslogik (die das natürlich auch prüfen würde, zum dann geeigneten Zeitpunkt).

[defo]

Möglicherweise eine sehr softwarephilosophische Betrachtung der Geschichte. Aber etwas das während ich tippe passiert ist keine Businesslogik sondern nur Logik der UI. Die Daten die da entstehen sind volatil und noch nicht Teil eines tatsächlich auf Businessregeln prüfbaren Konstrukts. Oder anders ausgedrückt während ich die UI bearbeite werden die meisten temporären Zustände der UI nach den Businessregeln ungültig sein. Das hier angesprochene Feld könnte zum Beispiel nur ein Komma enthalten. Das sollte gültig sein für die UI aber nicht für die Businesslogik. Der Feldinhalt wird erst nach einem bestimmten festzulegenden Zeitpunkt zu einem , dann hoffentlich gültiges Teil, der Daten und damit gegen Businessregeln sinnvoll prüfbar. Eine Formatprüfung ob ein string ein gültiges float format hat oder noch ergeben kann während der Eingabe ist also UI Logik und nie Businesslogik. Sollte man das so gemacht haben und nicht halbwegs getrennt haben würde ich für dieses System in Zukunft bei bestimmten Erweiterungen mit Problemen aus dieser Ecke rechnen.
Wie ich es auch gerne ausdrücke das hier ist ein reines Quality of Life Feature der UI unabhängig von der Businesslogik (die das natürlich auch prüfen würde, zum dann geeigneten Zeitpunkt).

Da würde ich sanft (in Teilen) widersprechen. Eine Businesslogik kann durchaus auf Feldebene gelten und während der Eingabe in Kraft gesetzt werden. Dabei gibt es vermutlich durchaus Fragestellungen, die die Durchführung dessen betreffen und am Ende den (gefühlten) Komfort eines solchen Eingabefeldes. Ganz "gewöhnliche" Feldtypen, deren Natur als Ganzzahl bspw. die Eingabe von Text sperrt, sind ja alltäglich. Wieso treibt man dieses Prinzip nicht weiter? Tatsächlich tut man es ja. MaskEdit Komponenten für die GUI sind ja nicht ungewöhnlich. Überhaupt ist ja eine weitgehende Eingabe-Validierung (bspw. Passwortdialog: zu kurz, enthält Teile des Usernames, keine Großbuchstaben, ..) in der GUI sehr weit verbreitet. (Was in dem Passwort Beispiel nicht gerade wirklich eine echte Business Rule darstellt)
Also kann man festhalten: Es gibt UI Komponenten, die validieren (können) und sie werden vielfältig genutzt.
Frage ist doch eigentlich nur, wie weit man das treibt.

Nimmt man bspw. eine solche Maskedit Komponente und versorgt die UI zur Laufzeit aus dem Backend (Business Rules) mit der an dieser Stelle vorgesehenen Maske oder Regex Prüfung, hat man alles erreicht. Das UI macht durchaus eine Prüfung, aber die Regeln kommen aus dem Backend. Die Fähigkeit zur Prüfung muss natürlich im UI implementiert sein.

[Ralf Jansen]

Gut das ich das mit der softwarephilosophie vorgeschoben habe

Was hilft mir die Maske für eine bestimmtes Control in der Businesslogik? Die soll Daten auf Konsistenz prüfen damit es im Systeminneren funktioniert. Der sollte völlig egal sein ob die Daten aus einer UI, einer API, einer Datenbank oder sonst woher kommen. Was du beschreibst ist oberflächliches Verhalten und gehört damit auch zur Oberfläche (aka UI). Das man das nicht einfach wild in einem schlechten Stil irgendwohin programmiert sollte selbstverständlich sein. Das kann man bei Bedarf natürlich irgendwo zentralisieren. Aber es ist eben nicht Businesslogik sondern UI Logik da es zwischen dieser Logik und einer speziellen UI eine 1 zu 1 Beziehung gibt. Ich brauche sie mit hoher Wahrscheinlichkeit für einen anderen Zugang zum System nicht.

Noch mal anders ausgedrückt. Du sprachst von Eingabenvalidierung. Die brauch man, sie hängt aber von der Eingabeform ab und gehört damit zur Eingabe und nicht in was mehr zentraleres. Für eine graphische Oberfläche sind es irgendwelche Masken oder 'as-you-type' Regeln. Z.B bei einer reinen API zum System wären es allgemeine Formatprüfungen wie ob das übergebene gültiges JSON, XML oder was auch immer. Auch das braucht man, ist aber auch abhängig von der konkreten API und gehört damit nicht in die Businesslogik sondern zu dieser API. Die sollte ja bestenfalls nicht mal wissen das es sowas wie JSON, XML gibt.

[fanderlf]

Ich meinte eher:

Heutzutage gibt es doch sowieso überall Two way databinding. In dem Model dahinter lassen sich sehr einfach Kommas entfernen, wenn mal eines zu viel in der Textbox im UI landet. Dort ist der Code meines Erachtens nach besser aufgehoben, als in einer eigens entwickelten UI Komponente. Aber vermutlich ist das alles aber eine Geschmacksfrage und dann sooo wichtig auch wieder nicht