Hallo,

EcoSpace funktioniert ja ganz gut, allerdings ergeben sich aus der Tatsache dass alle Daten in einem Cache liegen gewisse Probleme. Zum Beispiel: Wenn ich in einem Control den Wert aendere wird der neue Wert beim Verlassen des Feldes sofort in den Eco Space uebertragen und wie eine Lawine alle Subscriptions informiert. Eine Folge ist zum Beispiel, dass sich die Sortierung in ListBoxen aendert, und ggf. das aktuelle SelectedValue sich aendert. Das ist noch eines der harmloseren Folgen. Meine Frage ist nun: gibt es eine Moeglichkeit dieses sofortige Uebertragen in den EcoSpace zu verzoegern, Z.B. bis ein Update Button gedrueckt wird. Bei herkoemlichen DB Anwendungen tritt das Problem nicht auf, da alle Ergebnismengen voneinander unabhaengig sind.

Carsten

Hallo Carsten,

eine sehr interessante und wichtige Fragestellung, wie ich finde.

Ich denke mal, je nach Anwendungsfall könnte eine Option sein, das Data Binding gar nicht erst zu nutzen, z.B. indem ein Objekt dupliziert wird, Änderungen können dann beliebig durchgeführt werden, am Schluß (nach Klick auf den OK-Button) werden dann die Attribute wieder zurück übertragen.

Ich kenne halt Deine Anwendung nicht. Wäre das denn eine Lösung, die für Dich in Frage käme?

Viele Grüße,

Erik

Hallo Carsten,
ich beschäftige mich zur Zeit auch mit ECO.
Kann dein Problem folgendermassen gelöst werden !?!?
WinFormDequeuer.Active:=false;
Siehe ECO-Buch von Hr Schmid Seite 205

mfg
Hans

Hi there Hans,

fast ! ich brauche sozusagen das Gegenteil: Aenderungen in den Controls sollen nicht sofort (beim Verlassen des Feldes) in den EcoSpace weitergereicht werden. Wuerde mir wuenschen dass es eine Eigenschaft der Handles gibt, die Aenderungen cachen, und dann beim Aufruf einer Methode an den EcoSpace weitergeben.

Trotzdem danke, die Klasse WinFormDequeuer hatte ich auch uebersehen. Kann an anderer Stelle nuetzlich sein.

Servus

Carsten

Hallo Carsten!




Habe auch erst so gedacht. ECO ist aber so ausgelegt, dass jedes Feld sofort beschrieben wird. Dein Cache-Problem habe ich bei mir über den UndoService gelöst. Z.B. beim Verlassen einer Zeile im Grid wird StartUndoBlock( 'xxx' ) aufgerufen. Werden jetzt Daten geändert und in eine nächste Zeile gesprungen, wird analysiert ob der geänderte Datensatz OK ist (Vlidierung mit Constraints z.B.). Wenn nicht wird ein Undo aufgerufen und die Änderungen werden rückgängig gemacht. Insofern ist das Verhalten identisch mit dem Cachen im Editierpuffer des aktuellen Datensatzen beim alten TDataSet. Im Gegensatz zu alten Vorgehensweisen ist die GUI verantwortlich für dieses Verhalten und nicht das TDataSet Objekt. Mir persönlich gefällt die Vorgehensweise in ECO besser, da hier die Möglichkeit besteht, den Cache (also UndoBlock) auf mehr als einen Datensatz zu erweitern. So können mit einem einzigen Befehl die Änderungen an einem Master-Detail-Formular rückgängig gemacht werden, wenn irgendwas nicht passt.

Gruß
Thomas Wolf

Hallo Carsten!




Habe auch erst so gedacht. ECO ist aber so ausgelegt, dass jedes Feld sofort beschrieben wird. Dein Cache-Problem habe ich bei mir über den UndoService gelöst. Z.B. beim Verlassen einer Zeile im Grid wird StartUndoBlock( 'xxx' ) aufgerufen. Werden jetzt Daten geändert und in eine nächste Zeile gesprungen, wird analysiert ob der geänderte Datensatz OK ist (Vlidierung mit Constraints z.B.). Wenn nicht wird ein Undo aufgerufen und die Änderungen werden rückgängig gemacht. Insofern ist das Verhalten identisch mit dem Cachen im Editierpuffer des aktuellen Datensatzen beim alten TDataSet. Im Gegensatz zu alten Vorgehensweisen ist die GUI verantwortlich für dieses Verhalten und nicht das TDataSet Objekt. Mir persönlich gefällt die Vorgehensweise in ECO besser, da hier die Möglichkeit besteht, den Cache (also UndoBlock) auf mehr als einen Datensatz zu erweitern. So können mit einem einzigen Befehl die Änderungen an einem Master-Detail-Formular rückgängig gemacht werden, wenn irgendwas nicht passt.

Gruß
Thomas Wolf