Office: (Office 2003) Unterformular nicht speichern

Ich steht grade auf dem Schlauch ...

Habe ein ungebundenes (Haupt-)Formular in dem ich (nacheinander) verschiedene gebundene Unterformulare öffne.

Mit welchem Befehl - vom Hauptformular aus gesehen - kann ich verhindern, dass der Inhalt des UFO gespeichert wird?
Hiermit klappt es definitiv nicht: Code:

:)

 

Du könntest im HF auf die Ereignisse des Formulars im UF-Steuerelement reagieren und z. B. als Reaktion auf BeforeUpdate das Speichern abbrechen.

Du könntest auch überlegen, ob du das Unterformular an ein ADODB-Recordst bindest und beim Recordset die Verbindung kappst. Dann kannst du dir sicher sein, dass die Daten im UF nicht gespeichert werden. *wink.gif*

Aber: warum lässt man Ändern überhaupt zu, wenn man die Änderungen nicht speichern will?

mfg
Josef

 

Ok, ich habe mich nicht deutlich genug ausgedrückt:
ich will es mal zulassen und mal nicht ... oder mit anderen Worten: ich möchte einerseits die nette Eigenschaft der gebundenen Formulare, Änderungen an Daten ohne weitere Bestätigung speichern zu können, ausnutzen (der Benutzer soll nicht immer gefragt werden, 'willst Du das auch wirklich speichern') aber andererseits soll es auch die Möglichkeit geben, das Speichern abzubrechen (über einen Button im HF) bzw. nicht zu speichern, wenn das UF gewechselt oder geschlossen wird.

 

Also ist die Schaltfläche im HF das Problem. Denn sobald die den Fokus erhält, ist der DS im Unterformular bereits gespeichert, wenn es sich um ein über RecordSource gebundenes Formular handelt.

Bis wann soll das Rücksetzen der Änderungen über die Schaltfläche wirksam sein? Oder: ab wann darf gespeichert werden?
Wenn es nur für das eine UF gilt, dann könnte man die Schaltfläche doch auch im UF platzieren, oder?

Ich würde vermutlich den Ansatz mit dem Adodb-Recordset ausprobieren, wenn ich so etwas umsetzen müsste.

 

Hallo,
man könnte sich doch auch die ID des neuen Datensatzes im Ufo merken. Mit dem Button im HF könnte man dann fragen ob der Datensatz gespeichert werden soll. Wenn nicht, wird dieser wieder gelöscht. Ein eventuell vergebener Autowert ist dann zwar weg, aber das wäre er auch mit Undo.

 

Man könnte (sinngemäß) FAQ4.32 verwenden und statt der MsgBox einen Controlwert im Hauptformular abfragen.

 

Gibt es dafür exakt definierte Zustände?

Weil wenn ja, wie wäre es auf die Cancel-Anweisung des BeforeUpdate Events los zu gehen?

Cancel = MeinPruefungsRoutineObSpeichern

Wobei das eben die Rückgabe einer Funktion sein kann oder der Inhalt einer modulweiten Variabele.

Ist zwar recht primitiv aber funktioniert zuverlässig und funktioniert auch für den Fall des Button-Klicks auf das HF, zumindest wenn Du die Zuweisung an Cancel im Default-Falle auf True hälst, bzw. auf Cancel = Not xxxxxxxx.

Gruß

Rainer

 

Ich glaub das Problem stellt sich so dar, dass Hans-Christian im HF eine Schaltfläche hat, auf die der Anwender im Ausnahmefall klicken kann, um die Änderungen rückgängig zu machen. Das Reagieren auf ein Änderungs-Ereignis hilft in so einem Fall nicht, da das "Speicherverbot" nicht berechnet werden kann und der Anwender nicht bei jeder Änderung sein OK geben soll.

Einen Lösungsansatz hätte ich noch:
Die Schaltfläche "Änderungen rückgängig machen" gegen ein Bezeichnungsfeld austauschen und als Beschriftung "Drücken Sie die Esc-Taste, um die Änderungen rückgängig zu machen." verwenden. *biggrin.gif* *biggrin.gif* *biggrin.gif*

 

Wieso tut es das nicht?

Wenn die Standard-Rückgabe immer True ist und nur unter bestimmten Umständen auf False gesetzt wird, kann der User im UFO was ändern und dann auf die Schaltfläche im Hauptformular klicken um ein Undo auszuführen.

Der Speichervorgang beim Verlassen des UFO's findet wegen Cancel = True nicht statt.

Jetzt fehlt nur die Prüfung in welchen Fällen das automatische Speichern erlaubt sein soll (gibt ja nicht mehr viele ... wenn schliessen, UFO wechseln und UFO verlassen keine Speicherung auslösen soll, bleibt im Prinzip ja fast nur noch DS-Wechsel oder HF schliessen/DS wechseln) und diese Prüfung muss dann die Rückgabe auf False setzen damit Cancel = False ist.

Wie gesagt ... primitiv, aber effektiv wenn die Zustände wann erlaubt und wann nicht exakt definierbar sind.

Gruß

Rainer

 

Ein Szenario:
Der Benutzer wechselt in das Unterformular und ändert die Werte im Datensatz.
Nun will er die Änderungen rückgängig machen und klickt auf die Schaltfläche im Hauptformular.

Wie soll man diese Szenario mit einem Update-Ereignis lösen? Wenn das UF nachfragt ob gespeichert werden soll, ist der Button noch gar nicht betätigt.


Einen (für mich hässlichen) Ansatz hätte ich noch:
Bei der Reaktion auf das Ereignis in eine DoEvents-Schleife laufen, die z. B. eine Sekunde wartet, ob auf den Abbrechen-Button geklickt wurde und sonst das speichern zulässt. (Beim UF-Source-Wechsel usw. wird sofort freigegeben.)
/edit: nun weiß ich auch, warum mir der Ansatz nicht gefällt: er funktioniert nämlich gar nicht. *biggrin.gif*

 

Hallo,
ich möchte noch mal auf meinen Vorschlag aus #5 verweisen. Das könnte doch ein brauchbarer Vorschlag sein. Rückfragen und wenn nicht gewünscht wieder löschen. Es wäre ja immer der letzte datenstz der zu löschen wäre. Das vereinfacht doch die Sache.

 

\@ gpswanderer

Wenn ich hcscherzer richtig verstanden haben wollte er genau das nicht.

Denke da liegt das Problem, eben die automatische Speicherung von gebundenen Formularen zu nutzen aber diese eben in speziellen Fällen zu vermeiden ... ohne Rückfrage beim User.

Zumindest lege ich die Beschreibung des Problemes von hcscherzer so aus. ^^

Gruß

Rainer

 

Hans-Christian müsste definieren, ob das Verhindern des automatischen Speicherns des aktuellen Datensatzes jeweils
- vorab eingestellt oder
- nachträglich rückgängig gemacht werden soll.
Im zweiten Fall müsste man nicht nur die ID für ein eventuelles Löschen, sondern auch die OldValues zum Rückändern speichern.

Das "Speichern abbrechen" kann man bei Datensatz-/Formularwechsel bei einem an eine Tabelle/Abfrage gebundenen Formular vergessen.

 

\@Klaus: dein Ansatz funktioniert sicher ohne Probleme, wenn es sich um neu angelegte Datensätze handelt, die dann doch nicht benötigt werden.
Damit Hans-Christian aber auch auf Änderungen von bestehenden DS so vorgehen kann, müsste er sich jeden DS noch einmal extra merken und dann eine Update-Anweisung schicken bzw. in die Formularfelder die alten Werte eintragen, falls die Änderungen nicht erwünscht sind.

Diese Variante mit dem Zwischenspeichern wäre allerdings relativ schön in einer Hilfsklasse unterzubringen, die man bei Bedarf einsetzt. Und wenn man sie nicht einsetzt, funktionieren die Formulare auch, dann funktioniert nur das "Rückgängig machen" nicht. *wink.gif*

 

Oops ... hatte den Beitrag irgendwie übersehen von Dir. ^^

So z.B.:

Code:

Wie gesagt ... primitiv aber wirksam. Zumindest glaubt der User das die Undo-Anweisung ausgeführt wurde weil er den Button geclickt hat.

Nachteil an der Aktion ... in dieser Form würde die Undo-Anweisung bei jeglichem Formular verlassen ausgelöst werden.

Allerdings könnte man anstatt modulweiter Variabele eine Routine aufrufen die False/True zurück gibt. Die könnte bei Verlassen der Form - wenn BeforeUpdate ausgeführt wird - die Zeigerpostion checken lassen um raus zu finden ob der Mauszeiger über dem button/in Richtung des Buttons unterwegs ist oder eben woanders. Oder eben sorgen das wenn der Mauszeiger über dem Button ist eine boolsche Variabele auf True gesetzt wird und wenn der Mauszeiger woanders ist auf False ... die boolsche Variabele könnte dann in der Routine für die Cancel-Rückgabe geprüft werden.

Wobei immer noch die Frage ist wieso das Undo eigentlich aus dem HF aufgerufen werden muss?

Gruß

Rainer