Amelie schrieb:

Habe mir ein DataTable mit BindingSource etc aufgebaut und lasse die Textboxen für Eingaben dahingehend prüfen

Du könntest ev. über die Binding-Klasse deine Eingabe über das Parse-Event prüfen und damit eine mögliche Exception vorbeugen...
Du musst aber vorher mit dem Designer das vorhandene Binding von der Textbox lösen!
Natürlich wird deine Textbox über die Bindingsource zu Fuß per Benutzer-Code angelegt (siehe die Methode BindControl im Beispiel)!
Und dann kannst du das Parse-Event nützen, um deine Eingaben auf Korrektheit prüfen...
Schaue dir dazu eventuell das Format-Event an - damit kannst du deine Eingaben formatieren...

@Amelie Im Debug-Code mit Compilerschalter machst Du ein Debugger.Break(), damit Du Exceptions, die durch Programmierfehler entstehen, sofort untersuchen kannst:

Die ganze Eingabeprüfung kannst du auf eine Zeile reduzieren

Amelie schrieb:

Das mit dem Compilerschalter verstehe ich noch nicht.

Also du kannst in den Projekteigenschaften solche Sachen festlegen, für jede Buildeinstellung.
Im Code kannste dann je nach Buildkonfiguration unterschiedliche Sachen anstellen.

Geh mal in die Projekteigenschafte, reiter Kompileren, erweiterte Kompilierungsoptionen. Siehe Screenshot, oben siehst du die konfiguration(Debug/Release) wie auch Platform, jenachdem was du da einstellst, bevor du auf erweiterte Kompilieroptonen klickst, gilt das was du dann einstellst für diese Konfiguration. So kannste dir für jede Kombination(z.B. Debug + x64, oder release + x86) Werte anlegen, hast du eine weitere konfiguration angelegt zusätzlich zu Debug, kannste auch dafür sowas festlegen, beim kompilieren sieht der Kompiler was für die aktuelle Buildeinstellung festgelegt ist und du kannst im Code "switchen" so wird entweder der eine oder ein anderer Code an dieser Stelle kompilert. Legst du z.B. neben Debug und Relaese eine weitere Option an, z.B. mit dem Name ExtendedDebug und schreibst für diese Einstellung dann nur ExtendedDebug in die TB in den erweiterten kompiliereinstellungen, ist das definiert, auch wenn du keinen Wert zuweist, jenach buildeinstellung kannste auch verschiedene werte für4 die konstante festlegen und abfragen.

Ich habe jetzt mal neben Debug/Release eine weitere Konfiguration angelegt und ExtendedDebug genannt. Für diese Buildeinstellung habe ich eine Konstante angelegt heist auch "ExtendedDebug "(kannste aber nnen wie du willst), ohne einen Wert zuweisen. Im Code kann ich dann so unterschiedlichen Code kompileren. Dabei habe ich bei dieser konfiguration auch die Checkbox bei DEBUG konstante definieren unchekced.

Wie du auf dem 2. Bild sehen kannst, ist der Code im DEBUG bereich ausgegraut, dann bekommt x den Wert 20.
Schalte ich nun die Konfiguration wieder auf Debug um, würde x den Wert 10 haben, bei release würde es bei 0 bleiben.

Nicht immer stelle ich alle Funtionen eines Programms im releasebuild zur Verfügung, so kannste dann schnell und einfach festlegen, ob die normale oder erweiterte Version kompiliert werden soll. Oder wenn ein Client probleme mit dem Programm hat, kannste dem so einen releaseBuild geben der alles loggt, dir das log dann geben lassen um Fehler zu beseitigen.

@RodFromGermany Wozu


Gibt es irgendeinen Grund eine Debug-Version anzuhalten, wenn kein Debugger angehängt ist?


Reicht doch völlig oder. Unter Umständen ist das sogar hilfreich, für den Fall, dass man mal eine Release-Version debuggen muss. Kommt ja auch mal vor, wenn auch selten.

Yanbel schrieb:

Gibt es irgendeinen Grund eine Debug-Version anzuhalten, wenn kein Debugger angehängt ist?

Ja gibt es, du kannst ja einen Debug Build von Hand starten, (die exe via doppelklick), dann hängt kein debugger dran.

@Takafusa
Meine Frage war nicht, ob das möglich ist, denn dessen bin ich mir sehr wohl bewusst. Meine Frage war, in welchem Szenario dies sinnvoll sein soll / jemals benötigt werden sollte.

In Anspielung darauf das #If DEBUG Then realistisch betrachte eher selten irgendeinen Nutzen erfüllt und ganz sicher nicht in dem oben beschrieben Szenario. An dieser Stelle ist das meiner Meinung nach einfach redundanter unnützer Code, weil mir persönlich kein Szenario einfällt in dem man einen break macht ohne angehängten Debugger.

Yanbel schrieb:

An dieser Stelle ist das meiner Meinung nach einfach redundanter unnützer Code, weil mir persönlich kein Szenario einfällt in dem man einen break macht ohne angehängten Debugger.

Pack mal Deinen und meinen Code in den IlSpy.

@RodFromGermany Kann ich leider gerade nicht, ich bin noch unterwegs. Ich vermute aber mal, dass du darauf hinaus willst, dass dein Code im Release nicht kompiliert wird und meiner schon.

Wie bereits in Post #7 geschrieben und in Post #9 wiederholt, ist das hier aber gar nicht die Frage, sondern vielmehr ob das generell oder speziell für den Anwendungsfall des TE sinnvoll ist, weil man ja ggf. auch Release-Versionen nachträglich debuggen muss, wo Breaks im zentralen Errorhandling unter Umständen durchaus hilfreich sein können. Ausgeführt wird der Code doch ohnehin nur, wenn ein Debugger angehängt wird. Und mit Performance braucht mir hier auch keiner kommen. Die Abfrage eines oder einer Million bool-Variablen ist nicht sonderlich Performance-intensiv hab ich gehört, stört also auch nicht im Release. Schön je nachdem wieviel Code man in diese Tags reinschreibt kann das Kompilieren sich unter Umständen leicht verzögern, aber seien wir mal ehrlich, wenn das tatsächlich der Fall sein sollte, dann hat der Entwickler grundlegend was falsch gemacht. Also wo ist der Nutzen?

Ich frage an dieser Stelle bewusst provokant, weil wir auf der Arbeit gerade im gesamten Programmcode #If DEBUG Then rausgeschmissen bzw in wenigen Fällen durch if (Debugger.IsAttached)) ersetzt haben. Mich würde tatsächlich mal interessieren, ob irgendjemandem hier ein guter Grund einfällt, dieses Code-Tag jemals irgendwo zu verwenden.

Yanbel schrieb:

im gesamten Programmcode #If DEBUG Then rausgeschmissen

Wir nicht.
Ich arbeite sehr gern damit, auch ist bei uns in vielen Datenklassen die ToString()-Überladung nur im Debug vorhanden.

Wir sind irgendwann dazu übergegangen, dass sich unsere Entwicklungsumgebung genau so verhalten muss, wie die Live-Umgebung des Kunden. Ich benutze DEBUG-Schalter generell nicht, meine Kollegen noch ab und an für Fälle wie SELECT * FROM Customer-> SELECT TOP 1000 * FROM Customer, um Ladevorgänge zu verkürzen, etc. Ich habe noch nie einen Nutzen darin gesehen. Dann lieber vernünftigt Debuggen. Der einzige Punkt wo ein Schalter wirklich wichtig und sinnvoll ist, ist bei Außenkommunikation. Mailversand und Datentransfer in externe Systeme sollten in Testumgebungen unterbunden werden. Das war der einzige Punkt den wir unangetastet gelassen haben.

Wenn ich einen Rechner ohne Hardware habe, kann ich mit Compilerschalter eine Hardware-Simulation laden, um am Rest des Programms zu arbeiten.

Amelie schrieb:

Jetzt meine Frage: Ist das so "erlaubt"?

Naja, bei einem Spiel-Programm ist natürlich alles erlaubt, was kompiliert.
In der Praxis kommts dann auf den Einzelfall an, ob sowas "erlaubt" ist - meist ist es das nicht.

Du hast da jetzt etwas gebaut mit einem Speicher-Vorgang, und wenn das Speichern fehlschlägt, erscheint eine Meldung, und das Programm läuft weiter.
In der Praxis - etwa bei der Eingabe von KundenDaten - wäre so etwas extrem heikel.
Weil wenn so eine zentrale Funktionalität wie das Abspeichern von KundenDaten nicht funktioniert, dann darf das Programm nicht weiter benutzt werden.
Es muss geschlossen werden, so unschön das auch sein mag.

Amelie schrieb:

Habe meinen Code nochmal überarbeitet und die Textboxen gegen Combos getauscht. Eingestellt als "DropDownList" und wieder an die BindingSouce gebunden.

Eine ComboBox, die an eine gefüllte BindingSource gekoppelt ist, hat immer eine getroffene Auswahl. Eine Überprüfung auf Nichtauswahl wäre daher überflüssig, da das nie eintreten kann - es sei denn, man fummelt an der BindingSource/Datenquelle rum.
Meine ClearableComboBox kann sowas, aber die normale ComboBox im Zusammenhang mit einer BindingSource nicht.

Amelie schrieb:

Kann man das Prog dann nicht in " schön " bzw dann " kontrolliert " herunterfahren?

Bei einer unerwarteten Exception wird eine sinnvolle Log-Datei geschrieben, eine MessageBox mit einer sinnvollen Ausschrift gezeigt, z.B. soll die Log-Datei an Dich gesendet werden, und das Programm wird beendet.

Sind alle ComboBoxen an BindingSources gebunden und diese an das typisierte DataSet? Kommen die Daten bei Programmstart ins tDS oder erst später?