Checkbox Binding

  • VB.NET

Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von rrobbyy.

    Checkbox Binding

    Hallo zusammen,

    ich habe an ein typed Dataset gebundene Checkboxes über die Datenquellen in das Windows Form gezogen. Läuft auch alles.
    Da die Boxen ja an die Daten gebunden sind, wird das Häkchen nach dem Laden der Daten gesetzt oder nicht. Klar soweit.

    Falls jedoch die Datenquelle bei dem Datensatz in der jeweiligen Spalte NULL enthält, kommt die Checkbox in den Zwischenstand mit Indeterminate. Auch klar soweit - 0 und 1 bzw. False und True gibts ja nicht. Der Threestate ist false.

    NUR...ES NERVT MICH :D

    In den Designer-Eigenschaften der Checkboxen unter Databindings (Erweitert) kann man für NULL einen Wert setzen. Also bspw. 0. Dann würde die Checkbox komplett unchecked sein und nicht diesen Zwischenzustand anzeigen. Traumhaft und klappt, wie soll.

    Nur, wie komme ich per Code an genau diese Eigenschaft? Wie der Designer die Datenbindung macht, sehe ich und ich sehe auch den von mir vorgegebenen NULL-Wert. Nur das hilft mir nicht, weil ich nicht explizit sagen kann das NULL = 0 sein soll, da es anscheinend ausschließlich im Konstruktur festgelegt wird.
    Ich möchte auch nicht 20 Checkboxen einzeln markieren und dort die 0 eintragen.

    Daher die Frage, da meine Recherche bis jetzt zu nix führte...
    Wie kann ich denn per Code durch alle Checkboxen durchgehen und diesen NULL-Wert bei den Bindings setzen?

    Klar. Ich könnte im SQL-Server den Default-Wert auf 0 setzen, aber nö. :D

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

    rrobbyy schrieb:

    NUR...ES NERVT MICH
    Klar. Ich könnte im SQL-Server den Default-Wert auf 0 setzen, aber nö.
    Das ist aber der Königsweg.
    Wobei du zusätzlich DbNull garnet erst erlauben solltest - sofern nicht zwingende Gründe dafür vorliegen, NullWerte doch zu erlauben.

    Auch kleine Fehler im Datenmodell kosten - Nerven + Zeit, und da kommen noch weitere (Nerven-)Kosten hinzu, wenn du die Werte im Dataset benutzen willst, und sie sind tatsächlich mal Null.
    Tatsächlich hören die Kosten niemals auf, solange du an der Anwendung arbeitest. Insbesondere Support sogar ausgelieferter Anwendungen verteuert sich, weil man bei ProblemAnalysen jedesmal neu die komischen Workarounds neu verstehen muss, die man evtl. Jahre zuvor 'verbrochen' hat.

    Also: Probleme, die durch Datenmodell-Fehler entstehen, unbedingt - wenn irgend möglich - auch durch Korrektur des Datenmodells lösen.
    Keine Workarounds, die den eigentlichen Fehler bestehen lasssen.

    Ich rate ja immer davon ab, frühzeitig eine Datenbank zu hinterlegen. Man kann die meisten Datenverarbeitungen zu 90-100% implementieren mit einem Dataset, dass statt in die Db geschrieben wird, einfach mit Dataset.WriteXml auf Platte.
    Den Ansatz nenne ich "DatasetOnly", und hat viele Vorzüge (Performance, Flexiblität, Wartbarkeit, Kommunizierbarkeit,...). In deinem Fall handelt es sich um Wartung des Datenmodells, und da hat man halt die A...Karte, wenn man die DB und das Dataset modifizieren muss, statt nur das Dataset.
    Daten laden und speichern
    mist...warum habe ich gewusst, dass du jetzt so antwortest :D

    hast natürlich recht. ch bin auch ein freund davon, so viel wie möglich durch das dbms bzw. die datenbank machen zu lassen. ist wirklich ungemein einfacher.

    ein update-befehl zu setzen, der die spalte bei allen NULL auf 0 setzt, ist ja in ein paar sekunden gesschrieben. daran habert es nicht.
    wie dem auch sei...Dann belassen wir das beim "Königsweg" und haken das als als "nice-to-have-aber-unnötige-und-komplzierte-idee" ab.

    aber falls jemand lust und langeweile hat, kann man mich gerne jederzeit darüber aufklären...macht ja nicht dümme...

    ja. ich muss tatsächlich bestehende DBs um etliche Funktionen erweitern. Wirkliche Neuentwicklungen sind selten geworden....