SLE-Part mit preblock

[Martin Altmann]

Dieter,
die Berechnung darfst Du dann halt erst durchführen, wenn alle Werte eingegeben sind. Dazu musst Du in der Berchnungsfunktion entsprechend prüfen!
Der Nutzer kann die Werte in wilder Reihenfolge eintragen - da hast Du ja keinen Einfluss drauf! Er könnte sogar mit dem Wert im 12 SLE beginnen.
Übrigens brauchst Du weder privatevariablen, noch childlist-Tricks. Wenn Du beim Aufruf Deiner Funktion die Inhalte der SLEs als Parameter mitgibst, hast Du zwar viele Parameter (12), aber nichts von dem, was Dich ärgert.

Viele Grüße,
Martin

[Werner_Bayern]

und wenn man dazu noch ein

Code: Alles auswählen

#define BERECHNECODEBLOCK {||Berechne( ::Sle1:EditBuffer(), ::Sle2:EditBuffer(), ::Sle3:EditBuffer()) }

macht und dieses Define in den jew. SLEs als killInputFocus schreibt, dann ist der Code auch leicht wartbar, wenn sich mal was ändert.

[Dieter]

Hallo Werner,

das ist ein sehr interessanter Ansatz, den du mit deinem #DEFINE BerechnungsBlock herstellst. Leider nicht flexibel genug, wenn man für jedes einzelne Eingabe-Sle genaue Werte-Bereiche einhalten muss, wie es sehr häufig der Fall ist. Wenn z. B. der Wertebereich von sle3 bis sle6 zwischen 0 und 100 liegen müsste und andere Sle-Objekte <> 0 sein müssen, dann sollte die Procedure Berechnung dies mindestens nach einem ENTER mit einem Focuswechsel zurück auf das beanstandete Sle-Objekt beantworten, wenn der Wertebereich nicht eingehalten wird.
Deshalb ist es wohl notwendig, dass man im Codeblock {|u1,u2,oSelf| Berechne(oSle1,..., oSle25, oSelf)} das oSelf mit gibt. Es muss aber in der Procedure Berechnung mit DO CASE- Konstrukten ersteinmal gefunden werden. Jedes Eingabe-Sle mit einzuhaltenen Wertebereich muss mit oSelf erstmal verglichen werden, bis man auf die Sonderbehandung bezüglich des Wertebereich reagieren kann. Aus diesem Grunde ist es meiner Meinung nach weiterhin empfehlenswert, die killInputFocus-Codeblöcke nur zum Einhalten des definierten Wertebereiches eines Sle-Objektes zu nutzen, insbesondere wenn man soviele verschiedene Sle-Werte bearbeiten muss. Der Code ist viel besser les- und wartbar, wenn nach jedem erzeugten SLE ein Codeblock erzeugt wird, der genau für die Einhaltung des hier erforderlichen Wertebereiches zuständig ist.
Ich gebe jetzt aber zu, dass insbesondere durch #Define Berechnungsblock {|u1,u2,oSelf| Berechne(oSle1,..., oSle25, oSelf)} auch eine weitere Möglichkeit besteht, dass Lutz sein Programm schreiben kann. Ich hoffe, dass Lutz uns bald mitteilt für welche Methode er sich entschieden hat.

[Werner_Bayern]

Servus Dieter,

warum dafür nicht den validate - Codeblock verwenden? Alternativ kann man auch in jedem SLE im cargo-Slot eine Bedingung hinterlegen und in der Funktion berechne() einfach über oSelf:cargo prüfen.

Ich bin mir relativ sicher, dass man flexibel genug mit dem #define ist - soweit ich diese Anforderungen hier verstanden habe. Es gibt dazu ja 2 Ansätze: Entweder die Business-Logik gleich beim Control (SLE) hinterlegen, oder alles komplett in die Funktion berechne().

Im 2. Falle kann tatsächlich über die Childlist sauber auf alle SLEs zugegriffen werden - es muss also im killnputFocus-Block kein Parameter übergeben werden. Das geht schnell und ohne Privates.

[georg]

Hallo, Dieter -


in solchen Fällen leite ich eine eigene Klasse ab, die z.B. über eine :dasIstMeinName Instanzvariable identifiziert werden kann. Da geht der Vergleich recht schnell. Man kann sogar die Rechenregeln in solchen iVars hinterlegen und dann z.B. über :keyboard und den :editBuffer() während der Eingabe schon die Rechenergebnisse (vorläufig) ermitteln an anzeigen.

Also, SLE1 hat den Wert 12, die Regel ist Multiplikation. Wird eine 3 eingegeben, zeigt man 36 als Ergebnis an. Wird aus der 3 eine 32, dann lautet das Ergebnis 384 usw.

Es gibt enorm viele Möglichkeiten, das darzustellen, und jeder hat die Freiheit, sich die Variante rauszusuchen, die ihm gefällt, oder die zum eigenen Programmierstil oder den Vorgaben des Auftraggebers passt.

Ich finde Werners Ansatz mit dem #DEFINE spritzig, ist aber nicht meine Art, ich würde es wie oben beschrieben lösen.

[Dieter]

Hallo Werner,
Hallo Georg,

jeder hat halt seine eigenen Vorlieben und Präferenzen. Ich werde allerdings in Zukunft etwas vorsichtiger sein, hier jemanden zu kritisieren. Es kostet einfach zuviel Zeit, sich mit schon gelösten Problemen noch weiter zu beschäftigen. Diese immer weiter ausgedehnten Diskussionen bringen doch nichts. Es ist besser seine Zeit mit Opensource-Projekten zu verbringen, also echten funktionierenden Code zu besprechen, den jeder auch selbst testen kann.

[ramses]

Es ist besser seine Zeit mit Opensource-Projekten zu verbringen, also echten funktionierenden Code zu besprechen, den jeder auch selbst testen kann.

Hallo Dieter

heftige Aussage, aber wo gibts den wirklich gute XBase-OpenSource Projekte?

[Jan]

Dieter,

kann man denn verschiedene Lösungsansätze nicht diskutieren? Selbst dann, wenn der Threadstarter für sich schon eine Lösung gefunden hat? Das Forum ist doch dazu da sich auszutauschen. Ich selber habe schon mehrfach meine Meinung und Vorgehensweise geändert wegen solcher Diskussionen. Genau darum mag ich dieses Forum.

Und den Satz

Es ist besser seine Zeit mit Opensource-Projekten zu verbringen, also echten funktionierenden Code zu besprechen, den jeder auch selbst testen kann.

verstehe ich nicht. Diskussionen um "wie mach ich das am Besten, was sind die Vor- und Nachteile der verschiedenen Wege" ist Nonsens? Auch bei OpenSource gibt es immer unterschiedliche Lösungsansätze. Abgesehen davon haben wir hier im Forum stapelweise OpenSource. Als Lösungshilfen in den Diskussionen, und geballt in der Wissensbasis.

Jan

[Lutz Rübe]

Hallo an Alle,
erst einmal möchte ich mich ganz herzlich bei allen bedanken, die hier zur Lösung(sfindung) beigetragen haben.

Ich habe hier zu 100 % die Lösung des Problems gefunden - Danke nochmal an Dieter -, auch wenn meine Wunschvorstellung noch etwas darüber hinaus ging. Dazu wurden von allen für mich wertvolle Hinweise diskutiert. Es wurden mehrere Lösungswege aufgezeigt. Wie immer im richtigen Leben führen mehrere Wege nach Rom. Und warum soll man sich nicht gegenseitig diese Wege aufzeigen und darüber diskutieren?

Zum "Ton" in diesem Forum: wenn jemand von etwas voll überzeugt ist, wird sein "Ton" manchmal etwas deutlicher, aber deswegen hat sich hier keiner im Ton vergriffen!!!

Ich werde jetzt erst mal den Lösungsvorschlag von Dieter umsetzen und anschließend mich mit der Lösung über Methoden und Klassen beschäftigen. Der Umgang damit ist nämlich ein Schwachpunkt von mir, aber die Lösung, die sich da anbietet, reizt mich.


viele Grüße
Lutz

[Lutz Rübe]

so, ich hab jetzt mal mein Test-Programm fertig. Grundsätzlich sieht das gut aus und arbeitet - fast - wie gewünscht. Lediglich die unterste Zeile arbeitet nicht sauber: die Ergebnisse der ersten Felder werden erst dann korrekt ermittelt, wenn das oberste SLE ( 1, 4, 7 und 10) in der Spalte noch mal angesprungen wird. Habe ich da was falsch gemacht ? Die zweite und die dritte Zeile arbeiten wie gewünscht. Zum Nachvollziehen hier die Rechenregeln:
das SLE 14 berechnet sich aus der differenz von SLE 2 und SLE 3 multipliziert mit 50
das SLE 18 berechnet sich aus der Summe der SLE's 6, 9 und 12 multipliziert mit 30
das SLE 22 ist die Summe der SLE's 1, 14, 18 und 22.

Und super wäre es jetzt noch, wenn ich rausbekommen könnte, wie ich von SLE zu SLE mit der Enter-Taste springe und nicht immer die Tab-Taste benutzen müsste.

P.S.: das Programm ist noch mit xBase 1.9 erstellt.
Viele Grüße
Lutz

[brandelh]

das mit dem Enter geht so ... ENTER wird im SLE nicht intern verarbeitet (im Gegensatz zu MLE), daher wird der dann an den Keyboard slot weiter gegeben.
Man könnte nun mit PostAppEvent() das TAB lossenden, aber wenn es schon weitere Tastenanschläge gibt ...
Im Keyboard Event weiß man ja welches SLE es war und welches als nächstes kommen soll, dieses kann man dann den Input Focus zuweisen.