![]() |
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
Hallo Emilio,
ich habe die ersten vier Parameter der Berechnungsvorschrift mit den Aufrufwerten verglichen und dann mein Code-Studium wieder eingestellt, weil die für mich schon nicht zusammen passen. Bitte überprüfe deinen Prozeduraufruf gewissenhaft. Bei der Bereitstellung der Eingabe-Parameter-Werte fällt mir auf, dass du die Rechenwerte aus den Anzeigetexten konvertierst - das ist nicht nötig, da die Datenbank-Feldkomponenten Methoden besitzen, mit denen du direkt den Rechenwert erhältst (AsInteger, AsFloat). Wenn du deinen Code in Ordnung gebracht hast, dann gib einen Satz Eingabe-Werte und die erwarteten Ergebnisse an - so ist es leichter den Code zu testen. Ich kann leider nicht erkennen, welche Komponenten sich hinter bestimmten Namen verbergen (cxLookupCombo1). Gute Nacht marabu |
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
Hi Marabu,
sorry - ich check's wirklich nicht - kannst Du mir schreiben, was aus Deiner Sicht nicht zusammenpasst? Vielleicht entdecke ich dann des Pudels Kern. Möglicherweise hilft diese Beschreibung: Der User gibt einen Wert in cxTextEdit1 (DEVExpress-Kompo) ein = ekneu; wählt dann einen Zuschlagsatz aus der cxLookupCombobox1 aus = zuschlag; Daraus errechnet sich über die Funktion/Vorschrift f_bpneu der Wert bpneu. Alle folgenden Werte bauen auf dem ekneu und den "alten" Werten aus der Datenbank auf. Nachdem ich jetzt bei der Fehlersuche alle anderen Funktionen auskommentiert habe, stelle ich fest, dass auch dieser erste Schritt schon nicht funktioniert (Ergebnis = 0). Möglicherweise ist der Aufruf falsch, wenngleich er mit Deinem Beispiel übereinstimmt. Da mir die von Dir freundlicherweise angebotene Lösug vom Verfahren her (noch) fremd ist, tue ich mich verdammt schwer den Fehler zu finden. VG Emilio |
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
Hi Emilio !
Zitat:
Auch dort musst Du den Datentyp auf Extended ändern. Bei grösseren Anwendungen hat es sich sehr bewährt eine eigene Unit für alle Typdeklarationen, GlobalVariable und Konstanten zu erstellen. Dort könntest Du zB. definieren
Delphi-Quellcode:
und dann weiter
type
TMyFloat:Extended;
Delphi-Quellcode:
soll der Datentyp später geändert werden, muss dies nur an einer Stelle geschehen.
...
var BruttoLVPAlt, MargeEAlt:TMyFloat; ... Zu deinem Berechnungsproblem: Ziemlich komplexe Sache, schlage eine objektorientiertere Lösung vor. Kapsle die ganze Berechnung in ein Objekt und statte es mit properties aus. Dadurch vermeidest du auch die enorme Anzahl an Parametern. Überlege auch, ob es nicht sinnvoll wäre, die Daten in einem Record zusammenzufassen. Ich denke dass Du auf dem derzeitigen Weg nur schwer weiterkommst. :gruebel: Edit: Codebeispiel
Delphi-Quellcode:
Du könntest auf diese Art sogar eine Berechnungskomponente erstellen.
interface
type TMyFloat = Double; TBerechnung = class private FAltEK, FAltBP, FAltVP:TMyFloat; FNeuEK, FNeuBP, FNeuVP:TMyFloat; //... procedure SetNeuBP(const Value: TMyFloat); procedure SetNeuEK(const Value: TMyFloat); procedure SetNeuVP(const Value: TMyFloat); //... protected procedure Recalculate; public property AltEK:TMyFloat read FAltEK write FAltEK; property AltBP:TMyFloat read FAltBP write FAltBP; property AltVP:TMyFloat read FAltVP write FAltVP; property NeuEK:TMyFloat read FNeuEK write SetNeuEK; property NeuBP:TMyFloat read FNeuBP write SetNeuBP; property NeuVP:TMyFloat read FNeuVP write SetNeuVP; //... end; implementation { TBerechnung } procedure TBerechnung.Recalculate; begin // hier die Berechnungen durchführen // nur die privaten (F...) variablen setzen - nicht die Properties // würde sonst unerwünschte Rekursion ergeben, die mit einer // Variablen wie zB: Updating abgefangen werden müsste end; procedure TBerechnung.SetNeuBP(const Value: TMyFloat); begin if FNeuBP = Value then exit; FNeuBP := Value; Recalculate; end; procedure TBerechnung.SetNeuEK(const Value: TMyFloat); begin if FNeuEK = Value then exit; FNeuEK := Value; Recalculate; end; procedure TBerechnung.SetNeuVP(const Value: TMyFloat); begin if FNeuVP = Value then exit; FNeuVP := Value; Recalculate; end; |
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
Hi Ferber,
wow, das hört sich massiv an. Beim ersten Aufruf Deines Beitrags hab ich Dein Code-Beispiel nicht gesehen und dachte gleich, dass das ne Nummer zu hoch für mich ist; so siehts aber schon etwas machbarer für mich aus - Danke! Hm, Wien soll ja ne schöne Stadt sein; hättest Du im Prinzip mal Interesse und Zeit an Nachhilfe-Unterricht? VG Emilio |
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
@Ferber,
welch unglückliche Formulierung! - Ich meinte selbstverständlich Nachhilfe zu geben ! VG Emilio |
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
Hi Emilio !
Hab das Codebeispiel auch erst im Edit angehängt. Ganz verstehe ich das, was Du mit der Nachhilfe meinst, nicht. :stupid: Hier im Forum bekommen wir doch alle 'Nachhilfe', wenn's mal nicht weitergeht. VG Ferber :) PS: Um meine Zeit ist's leider schlecht bestellt, muss mich um meine Firma kümmern. |
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
@Ferber,
Betr.: Nachhilfe: habe nebenbei auch eine Compnay zu managen und ebenso ein permanentes Zeitproblem. Tatsächlich aber wäre ich bereit Zeit und Geld in gezielte Hilfestellung für mein Projekt zu investieren, da es mich schlussendlich entlasten soll. Zurück zum Thema: habe aus meinem Code alles rausgeworfen, bis auf den ersten Rechenschritt - und siehe da, das Ergebnis von BP ist "0" und der Compiler meldet, dass der Wert der Funktion f_bpneu nie verwendet wird ??? Teufel und die Axt! Ich bin drauf und dran nachma ganz von vorne zu beginnen. Hast Du ne Idee? VG Emilio |
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
Hallo Emilio, nur zur Erinnerung:
Zitat:
|
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
Hi Marabu,
eigentlich ist es egal, welchen Eingabewert für diese Procedure nimmt. Aber trotzdem ekneu = StroFloat(cxTextEdit1.Text) = 1000,00 dann sollte [ekaender] errechnet werden, als OnEditChange in cxTextEdit1 (da das Ergebnis von [ekaender] auf der Form1 in der Zeile von EKAlt und ekneu steht. EKalt = 1200,00 Also [ekaender] = ((ekneu/EKAlt)-1)*100 = -16,67 dann wählt man aus der cxCombobox1 einen zuschlagsatz [zuschlag] aus z.B.: 10 Also [bpneu] = ekneu+(ekneu*zuschlag/100) = 1100,00 [bpaender] ist dann wie bei [ekaender] ((bpneu/BPAlt)-1)*100. Als Vorschlag für den Wert [lvpneu] ist die Formel ekneu/55*100 hinterlegt [lvpaender] ist dann wiederum lvpneu/LVPAlt usw. Solange ich alles in einer Unit behalte und nicht in eine "CalcRule" packe (d.h. Funktionen im interface-Abschnitt deklariert, alle Werte mit denen gerechnet wird als Variablen im Implementation-Abschnitt ganz oben, funktioniert alles prima. Also habe ich vermutlich bei der Umsetzung Deines Vorschlags einen Aufruffehler verbaut (der u.a. bewirkt, dass die Variablen nicht initialisiert werden), den ich nicht finde. Dennoch würde ich gerne die Trennung in 2 Units bevorzugen, da es übersichtlicher und sicher nützlicher ist, da ja der User auch einen lvpneu( neuer Verkaufspreis) und eine margeprozneu (Marge in % vom neuen Verkaufspreis) als Basisdaten eingeben möchte und alle anderen Felder errechnet werden sollen. Ich werde jetzt den Code in der UnitMain so fertigmachen und dann den Versuch mit der Trennung neu starten. Falls Du den Fehler finden solltest - ich freu mich riesig auf Deine Antwort! VG Emilio by the wy: deutsch ist eine furchtbar umständliche Sprache! |
Re: komplexe Berechnungen von abhängigen Datenbankfeldern
Emilio, es ist eigentlich nicht egal - aber da du beim Aufruf der Berechnungsvorschrift ganz fundamentale Fehler machst, ist es auch wieder egal.
Eine gewissenhafte Überprüfung deines Codes hat folgendes zu Tage gefördert:
Delphi-Quellcode:
Wie du unschwer erkennen kannst, übergibst du die falschen Argumente für die festgelegten Parameter. Wenn du das in Ordnung gebracht hast, dann schreibe in der dritten Spalte unter Beispiel noch die Eingabewerte, mit denen ich testen kann. Ohne konkrete Testdaten mag ich nicht.
CalcRule01(
// argument parameter beispiel // --------------- ---------------- ------------- ekneu, // EKalt bpneu, // EKneu 1000,00 lvpneu, // BPalt margeEneu, // LVPalt margeprozneu, // BruttoLVPalt provlvpneu, // MargeEAlt bruttolvpneu, // MargeProzAlt ekaender, // ProvLVPAlt bpaender, // MwSt lvpaender, // ProvSatz bruttolvpaender, // zuschlag // var margeEaender, // bpneu margeprozaender, // lvpneu provlvpaender, // bruttolvpneu EKAlt, // margeEneu BPALT, // margeprozneu LVPAlt, // provlvpneu BruttoLVPAlt, // ekaender MargeEAlt, // bpaender MargeProzAlt, // lvpaender ProvLVPAlt, // bruttolvpaender MwSt, // margeEaender ProvSatz, // margeprozaender zuschlag // provlvpaender ); Freundliche Grüße vom marabu |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:29 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz