@Marabu,
Zitat:
Ganz anders die dazu passende Benutzerschnittstelle. Mit zunehmender Komplexität des Modells wird da ein OO-Ansatz unentbehrlich.
Benutzerschnittstelle - das ist das Stichwort:
Es gibt ingesamt 5 Edit-Felder in die der User Werte eingeben könnte (ekneu, lvpneu, bruttolvpneu, MargeE und Marge%).
Der ekneu kann z.B. über 3 Wege zustande kommen:
- User-Eintrag im ekneu Edit-Feld
- User-Eintrag im lvpneu-Feld und MargeE- oder Marge%-Feld (Berechnung)
- User-Eintrag im bruttolvpneu-Feld und MargeE- oder Marge%-Feld (Berechnung)
der lvp kann z.B. über 5 Wege zustande kommen:
- User-Eintrag im lvpneu Edit-Feld
- User-Eintrag im ekneu-Feld + Auswahl des zuschlag aus der Combobox (Auto-Vorschlag wie in CalcRule01)
- User-Eintrag im bruttolvp-Feld (Berechnung)
- User-Eintrag im ekneu-Feld und MargeE- oder Marge%-Feld (Berechnung)
- User-Eintrag im bruttolvpneu-Feld und MargeE- oder Marge%-Feld (Berechnung)
Die 7 Werte, welche die Änderungen neu gegen Alt ausdrücken (ekaender, xyaender, etc.) werden eigentlich immer dann benötigt, wenn zum passenden Alt-Wert ein neu-Wert eingegeben oder errechnet und angezeigt wird.
Mit den genannten Wegen decke ich jedoch nur die "primär"-Eingabe ab; Nicht erfasst sind Änderungen, die der User nach der Primär-Eingabe vornehmen möchte (z.B. den bruttolvpneu runden/glätten, die Marge prozentual anpassen, etc.).
Das hieße, nach der Ergänzung des Codes für die primär-Eingaben noch 7 onChange-Events mit unterschiedlichen "Calcrules" bauen - oder nicht? Irgendwie werde ich das Gefühl nicht los, dass ich das bisherige Konstrukt zerfleddern muß, um den User-Wünschen gerecht zu werden. Ich grübel weiter.
Falls jemand noch 'n Tipp hat - ich freue mich!
VG
Emilio