TDBEdit, TDBLookupComboBox, TField und OnSetText-Event

[r_kerber]

Moin moin,

ich habe folgendes Problem. Auf einer Eingabemaske befinden sich mehrere TDBEdit-Boxen und TDBLookupComboBoxen. Sobald in einem TBEdit ein Wert eingegeben/verändert wurde, wird in einem onValidate-Event-Handler eine Stored Procedure (für alle TFields wird dieselbe SP verwendet) auf gerufen, welche die anderen Feldwerte ermittelt. Diese werden dann in die entsprechenden DB-Felder geschrieben. Dadurch ändert sich natürlich auch der Wert der TField-Objekte und somit auch der Edit- und Comboboxen, was sofort wiederum ein neues onValidate für die TFields auslöst. Damit nun dadurch keine Endlosschleife ausgelöst wird, werden der Stored Procedure zwei zusätzliche Parameter übergeben, zum einen den Sender der das aktuelle onValidate ausgelöst und den "Initial_Sender", also das Object, welches das erste onValidate ausgelöst hat. Um diesen zu ermitteln wird zusätzlich das OnSetText-Event von TField abgefangen. Diese wird ausgelöst, unmittelbar nachdem man in einem TEdit einen Wert eingibt/ändert. Doch leider funktioniert das nur mit TDBEdit. Eine TDBLookupComboBox löst kein OnSetText-Ereignis aus, wenn ein anderer Eintrag ausgewählt wird. Ich suche nun eine Möglichkeit auch für eine LookupComboBox den "Initial_Sender" zu ermitteln, also etwas in der Art

• Element in TDBLookupComboBox ändern
• ComboBox verlassen
• irgendein Event --> Zwischenspeichern des auslösenden Senders
• OnValidateEvent --> Ermittel des aktuellen Senders, Starten der SP (mit den Parametern initial_sender und sender)
• ...

Und dieses "irgendein Event darf nur einmal ausgelöst werden, nachdem sich der in der Combobox etwas geändert hat.

[marabu]

Moin Rainer.

Das Problem mit Intra-Record-Abhängigkeiten hast du auch ohne eine Anbindung an eine Datenbank. Durch die Übermittlung von Sender und Initial Sender an die Stored Procedure schaffst du eine enge Kopplung zwischen GUI und Datenmodell. Ich würde versuchen die Steuerung vollständig im GUI zu belassen.

Für die einmalige Benachrichtigung darüber, dass der Inhalt eines Datenfeldes sich geändert hat, würde ich nicht auf das Ereignis OnSetText() der Field-Komponente, sondern auf das Ereignis OnDataChange() der DataSet-Komponente zurückgreifen.

Freundliche Grüße vom marabu

[r_kerber]

Moin Marabu,

Zitat von marabu:

Das Problem mit Intra-Record-Abhängigkeiten hast du auch ohne eine Anbindung an eine Datenbank. Durch die Übermittlung von Sender und Initial Sender an die Stored Procedure schaffst du eine enge Kopplung zwischen GUI und Datenmodell. Ich würde versuchen die Steuerung vollständig im GUI zu belassen.

Keine Chance. Das Programm arbeitet grundsätzlich so, daß die GUI tatsächlich nur zur Darstellung der DB-Inhalte und zur Steuerung des Ablaufes vorgesehen ist. Sämtlich Business-Logic ist in SQl und SP's in ie Datenbank ausgelagert.

Zitat von marabu:

Für die einmalige Benachrichtigung darüber, dass der Inhalt eines Datenfeldes sich geändert hat, würde ich nicht auf das Ereignis OnSetText() der Field-Komponente, sondern auf das Ereignis OnDataChange() der DataSet-Komponente zurückgreifen.

IMHO kommt TField.OnValidate vor TDataSource.OnDataChange, oder? Und damit wäre es zu spät.

[r_kerber]

Ich hole diesen Thread noch einmal nach oben.

[marabu]

Hallo Rainer,

wenn du für dein Datenmodell ein GUI implementiert hast, welches auf datensensitiven Komponenten basiert, dann erschließt sich mir der Sinn der Stored Procedure nicht ohne weiteres. Kannst du das noch ein wenig aufhellen?

Zitat von r_kerber:

Zitat von marabu:

... Ich würde versuchen die Steuerung vollständig im GUI zu belassen.

Keine Chance. Das Programm arbeitet grundsätzlich so, daß die GUI ... zur Steuerung des Ablaufes vorgesehen ist.

Das nenne ich einen Widerspruch.

Zitat von r_kerber:

IMHO kommt TField.OnValidate vor TDataSource.OnDataChange, oder?

Das ist richtig.

Zitat von r_kerber:

Und damit wäre es zu spät.

Genau das wollte ich hinterfragen. Bei mir ist es oft die einzig richtige Stelle.

Freundliche Grüße

marabu

[r_kerber]

Moin marabu,

Zitat von marabu:

wenn du für dein Datenmodell ein GUI implementiert hast, welches auf datensensitiven Komponenten basiert, dann erschließt sich mir der Sinn der Stored Procedure nicht ohne weiteres. Kannst du das noch ein wenig aufhellen?

Ich will es versuchen. Das Stichwort heißt Flexibität und Wartbarkeit. Denke Dir mal folgendes Szenario:
Eine Artikelverwaltung ist bei unterschiedlichen Kunden im Einsatz. Für jeden Artikel wird z.B. der Verkaufspreis anders kalkuliert. Du hast jetzt die Möglichkeit, diese Berechnungen im Programm fest zu verdrahten. Was macht nun der Kunde, wenn er einen Artikel hinzufügen will? Er müßte jedesmal das Programm anpassen und die Berechnungen einbauen. Und die einzelnen Kunden haben nun auch noch völlig andere Artikel. Das Programm würde zum Moloch werden oder man arbeitet mit kundenspezifischen Versionen. Der Ansatz ist nun, das diese Berechnungen ausgelagert werden. Dafür bietet sich eine DB wie ORACLE kann. Alles was weitestgehend standard bzw. kundenneutral ist wird über SP in einem Standard-Schema abgehandelt. Alle kundenspezifischen Berechnungen und DB-Aktionen befinden sich in dem jeweiligen Kundenschema. Kommt also ein neuer Artikel hinzu, werden Preisberechnung und alles andere in einer SP durchgeführt und über reine Parametrisierung dem jeweiligen Artikel zugewiesen. Das ist eine Arbeit von wenigen Stunden bzw. Tagen. Und glaube mir, ich kenne vergleichbare Programme, da ist das Einfügen eines neuen Produkts ein Projekt, daß mindestens über mehrere Monate geht.

Zitat von marabu:

Zitat von r_kerber:

Zitat von marabu:

... Ich würde versuchen die Steuerung vollständig im GUI zu belassen.

Keine Chance. Das Programm arbeitet grundsätzlich so, daß die GUI ... zur Steuerung des Ablaufes vorgesehen ist.

Das nenne ich einen Widerspruch.

Sagen wir mal so, die GUI ist lediglich der Workflow. Alle erforderliche Aktionen (Business-Logik) wird nur angestoßen und in der DB ausgeführt.

[marabu]

Danke für deine Erläuterungen, aber das bringt zumindest mich noch weiter weg von OnValidate(). Das Kalkulationsmodell eines Kunden per Customizing als SP zu hinterlegen ist sicher nicht das verkehrteste, aber warum muss das so eng an das GUI gekoppelt werden? Ich würde für diesen Zweck sogar das OnDataChange() fallen lassen und die SP in einem Before-Insert-Trigger aufrufen. Aber das ist eine grundsätzliche Design-Frage und du hattest ja eigentlich nur nach einem einmaligen OnChange-Event für eine TDBLookupComboBox gefragt. TField.OnChange() sollte bei dieser Komponente doch ausreichen?

Freundliche Grüße

marabu

[r_kerber]

Zitat von marabu:

Das Kalkulationsmodell eines Kunden per Customizing als SP zu hinterlegen ist sicher nicht das verkehrteste, aber warum muss das so eng an das GUI gekoppelt werden?

Das Programm ist nun mal so entwickelt worden und in dieser Form bei diversen Kunden im Einsatz. Und es wird nicht die die Business-Logik customized sondern auch welche GUI-Elemente wann angezeigt werden sollen und zum Teil auch welche (DBEdit, DBCombobox, ...). Das Erzeugen der GUI erfolgt somit im wesentlichen dynamisch zur Laufzeit. Dasselbe gilt für dir TStoredProc-Objekte.

Zitat von marabu:

Ich würde für diesen Zweck sogar das OnDataChange() fallen lassen und die SP in einem Before-Insert-Trigger aufrufen.

Die Berechnungen sollen ja schon vor dem Insert durchgeführt und dem Anwender in der GUI sofort angezeigt werden.

[marabu]

Hallo Rainer,

Zitat von marabu:

... du hattest ja eigentlich nur nach einem einmaligen OnChange-Event für eine TDBLookupComboBox gefragt. TField.OnChange() sollte bei dieser Komponente doch ausreichen?

für den Fall, dass du es übersehen hast - ich habe es auch schon getestet und es funktioniert.

marabu