Abhängigkeiten zwischen Eingaben in TEdit Felder elegant prüfen



  • Hallo,

    ich habe derzeit 12 TEdits in die Parameter eingetragen werden. Zwischen den Parameter bestehen Abhängigkeiten (z.B. soll ! min > max und min zwischen 0 und 1000 sein, etc.)

    Den Checken mache ich derzeit mit einem if und 28 mit && verknüpften Bedingungen.

    Wenn ich mir das so angucke frage ich mich ob es da nicht eine elegantere Lösung gibt 🙄 .

    Kennt jemand eine?

    mfG

    robi1806



  • hath deine anwendung den außer denn 12 edits noch andere edits denn mann kann alle edits anschprechen.
    Du verstehst mich doch oder?



  • Im Augenblick sind in der Form nur die 12 Edits, die ich wie folg checke:

    if (hmin->Text.ToInt()>=0 && hmin->Text.ToInt()<=249
       && Fmin->Text.ToInt()>=0 && Fmin->Text.ToInt()<2000
       && Qmin->Text.ToInt()>=0 && Qmin->Text.ToInt()<2000
       && POEmin->Text.ToInt()>=0 && POEmin->Text.ToInt()<500
    
       && hmax->Text.ToInt()>0 && hmax->Text.ToInt()>hmin->Text.ToInt() && hmax->Text.ToInt()<251
       && Fmax->Text.ToInt()>0 && Fmax->Text.ToInt()>Fmin->Text.ToInt() && Fmax->Text.ToInt()<2001
       && Qmax->Text.ToInt()>0 && Qmax->Text.ToInt()>Qmin->Text.ToInt() && Qmax->Text.ToInt()<2001
       && POEmax->Text.ToInt()>0 && POEmax->Text.ToInt()>POEmin->Text.ToInt() && POEmax->Text.ToInt()<501
    
       && nhclasses->Text.ToInt()>0 && nhclasses->Text.ToInt() < 1001
       && nFclasses->Text.ToInt()>0 && nFclasses->Text.ToInt() < 1001
       && nQclasses->Text.ToInt()>0 && nQclasses->Text.ToInt() < 1001
       && nPOEclasses->Text.ToInt()>0 && nPOEclasses->Text.ToInt()<1001)
       {
          //mach was
       }
       else ShowMessage("Es wurden ungültige Werte eingetragen.");
    }
    


  • Du kannst die Überprüfung in der OnChange oder der OnExit der Edits machen. Hat den Vorteil, dass Du dem Benutzer gleich sagen kannst, in welchem Feld der / die Fehler sind.

    Weiterhin solltest Du ToIntDef(Wert) verwenden, sonst kracht's wenn mal jemand aus Versehen einen Buchstaben eingibt.

    Ich persönlich würde die es vorziehen die Daten und Anzeigemodule zu separieren. Schau mal auf junix Homepage unter DocView.



  • Danke für die Tips. Junix DocView hab ich gerade gelesen: Prinzipiell natürlich interessant, in meinem Fall aber Kanonen auf Spatzen. Die Form ist Modal und sammelt nur kurz die Parameter für eine Auswertungsgrafik, die dann direkt erstellt wird.

    OnChange hatte ich vorher probiert, klappt aber nicht weil ich glaub ich beim dynamic cast nen Fehler drin hatte... werd's jetzt doch nochmal so probieren.
    Der Fehler ist mir witzigerweise beim lesen eines casts in junixs Tutorial aufgefallen, von daher wars trotzdem wohl die Lösung 🙂

    mfG

    robi1806



  • robi1806 schrieb:

    in meinem Fall aber Kanonen auf Spatzen. Die Form ist Modal und sammelt nur kurz die Parameter für eine Auswertungsgrafik, die dann direkt erstellt wird.

    Klingt für mich fast schon wie ein Widerspruch. Du sammelst Daten und wo speicherst Du die?
    Für mich böte sich hier ein (einfache) Klasse an, in der Du die Überprüfungen vornimmst und die Daten zwischenspeicherst. Eine Instanz dieser Klasse
    bekommt dann Dein modales Formular und wird anschließend an Deine Grafik (die vermutlich auf einem anderen Formular liegt) weitergereicht.
    Ich weiß natürlich nicht, was der Hintergrund hinter all dem ist, aber wenn irgendjemand irgendwann auf die Idee kommt, von der Grafik wieder zurück
    auf das modale Formular zu schalten oder vielleicht sogar das modale Formular nicht-modal zu gestalten, ist das mit einer dahinterliegenden Klasse
    nicht mehr so schwierig.

    Gruß,

    Alexander



  • Danke für das Feedback.

    Also ich frage mit der Modalform Parameter für die Rasterung von Werten ab.

    Meine Berechnungsklasse erstellt aus xmin, xmax, xAnzahlDerKlassen, ymin, ymax und yAnzahlDerKlassen dynamisch ein 2D-Array in welches die aus Txt-dateien gelesenen Werte eingeordnet werden. Anschliessend stelle ich die relative Häufigkeit der Klassen mit TChart dar. Abspeichern kann der Benutzer dann das Bild (TChart Funktion).

    Da die Rasterung mit 5000*250 Werten erfolgt dauert sie ca 80 Sec.
    Es wäre also nicht realisierbar, dass sich die Grafik mal schnell anpasst. Oder etwa doch? Daher muss der Benutzer wenn er anders rastern möchte den Menupunkt erneut anklicken, neue Parameter eingeben und eine neue Auswertung starten, die dann eine neue Instanz der Form mit dem TChart erzeugt.

    Abhängigkeiten die ich checke sind min und max für die Parameter und min<max.

    mfG

    robi1806



  • Keine Ahnung, ob sich die Grafik schneller berechnen lässt, aber die eingestellten Werte wirst Du doch hoffentlich irgendwo speichern.
    Oder muss der Benutzer jedesmal die Werte komplett neu eingeben. Auch wenn es nur wenige Werte sind, finde ich sowas immer lästig.
    Ich würde die Werte die Werte in irgendeine kleine Klasse packen - Du musst ja nicht gleich die ganze Geschichte mit update-Benachrichtigungen usw.
    einbauen. Mir erscheint nur die Aufteilung klarer und leichter erweiterbar. Dass Du im Moment keine Möglichkeit der Erweiterung siehst, heißt nicht,
    dass Du morgen keine siehst. Und je später Du dann eine Refaktorisierung vornehmen musst, um so schwieriger und fehleranfälliger (und damit teurer)
    wird sie.
    Du siehst schon: Mir geht's eigentlich eher ums Prinzip und um gute oder schlechte Gewohnheiten. Wenn man sich einen ordentlichen Programmierstil
    angewöhnt, fallen einem solche Geschichten auch viel leichter.
    Ansonsten kann es natürlich schon sein, dass ich hier übers Ziel hinausschieße 🙂

    Gruß,

    Alexander


Anmelden zum Antworten