Office: (Office 2010) Bei Before_Update feststellen wie speicherung ausgelöst wurde

\@JPA,

im Formular-Klassenmodul: Code:

In einem allgemeinen Modul: Code:

 

Ich habe hier auch ein kleines süßes Tool gebastelt, mit dem das geschilderte Problem gelöst werden kann.

Die Frage ist was geschehen soll wenn ein Dirty- Formular geschlossen wird. Es gibt 3 Möglichkeiten

1. Änderungen verwerfen
2. Änderungen speichern
3. Änderungen bearbeiten.

„Cancel“ = „true“ im Form_BeforeUpdate-Ereignis führt leider zu zwei Meldungen die den Benutzer quälen. Da muss noch bisschen dran gearbeitet werden!

Frithjof

 

\@Frithjof, lies #14.
Nach 20 bis 30 Kommentaren offenbart JPA dann immer was Sache ist. Für die Helfer immer eher frustrierend.
Da wundert er sich dann immer über die kleinen Seitenhiebe, denkt aber nicht daran, dass er sie selbst provoziert.

 

\@Frithjiof
Vielen Dank für dein Beispiel.
Es trifft nicht ganz meine Frage.
Bzgl. das Thema welches du dort behandelts würde ich es allgemeiner halten, in dem du es in einer Klasse auslagerst. So wa in jedem Formular zu hinterlegen wird aufwendig.

Hier eine kleine Anregung.
VG
JPA

 

\@Marsu65
vielen Dank für deine Antwort. Mir geht es um gebunde Formulare.

Nach den kommentaren, kann ich nun meine Frage präziser stellen (ist aber weiterhin die aus #1).
Wie kann festgestellt wie der Datensatzspeichervorgang ausgelöst wurde im Before_Update-Event um über das bekannt verfahren (cancel=true) ggf. den Vorgang abbrechen zu lassen.

Scheint, mit Bordmittel nicht realisierbar zu sein.

Ein Beispiel was mein Wunch hoffentlich veranschaulicht:
Bei forms2.0 gibt es das Event:
Private Sub UserForm_QueryClose(Cancel As Integer, CloseMode As Integer)

über CloseMode kann dann erkannt werden, "wie" der Schliessvorgang ausgelöst wurde.

VG
JPA

 

Hallo JPA.
In deinem Beispiel geht es um Datenvollständigkeit und Datenintegrität. =anderes Thema.

In meinem Beispiel wird erstens festgestellt ob der Ok-Button (bzw. andere) das Form_BeforeUpdate-Ereignis ausgelöst hat oder nicht, und zweitens ob sich Daten geändert haben.
Die geänderten Felder werden farbig hervorgehoben um dem Benutzer die Entscheidung ob speichern, verwerfen oder bearbeiten zu erleichtern.
Also das Beispiel erschlägt einen großen Teil der von dir geforderten Funktionalität.
(vielleicht kannst du mir das in eine Klasse packen?)

Aber es beantwortet nicht deine Frage, ob es feststellbar ist, wodurch das Form_BeforeUpdate-ereignis des Formulars ausgelöst wurde.
M.W. kann das nicht direkt mit einfachen Mitteln herausgefunden werden, sondern nur indirekt durch Prüfung verschiedener Fragen wie z.B. Was ist das aktive Kontrollelement? Wo befindet sich der Focus? usw..

Frithjof

 

Nur hilft dir das QueryClose Event nichts, wenn das Update Event davor ausgelöst wird.

Im Prinzip wird es so sein: Die Access Anwendung erhält vom Betriebssystem den Befehl das Form zu Schließen. Jetzt kommt das Update und sonstige Events. Danach wird das Unload Event ausgelöst - Wenn alles passt wird das Fenster endgültige entladen. (Falls es wer ganz genau weiß, bitte posten).

Vielleicht hat auch jemand Erfahrung wie man beim Sublassing genau vorgehen müsste. Ansonsten eignen sich die C-Foren für diese Themen. Oder man "probiert" halt eben.

 

\@Frithjiof
Nein/ja, bei meinem Beispiel ging es ums prinzip Auslagerung in klassen.
Für deine Anforderung habe ich hier ein Beispiel extra für Dich angehängt.

@markusxy

Absolut, des wegen was es nur ein Beispiel.

Im Prinzip wäre folgendes was es braucht:
Code:

Vielleicht was für access.usersvoice *grins

 

Hallo JPA

Dein Beispiel hat mit meinem Ansatz nichts zu tun. Es ist dasselbe worauf du bereits verlinkt hast.
Vermutlich hast du mein Beispiel nicht angesehen?

Vielleicht was für access.usersvoice *grins

Den Ansatz habe ich dir eigentlich geliefert, nur wird "UpdateMode" der Funktion nicht übergeben (wer soll das auch machen?) sondern innerhalb der Funktion ermittelt.

Ich vermute mal du willst hier nur Werbung für dein Zeugs machen? *wink.gif*

Frithjof

 

Danke für dein Beispiel, du prüfst ob die Speicherung über eine gewisse Schaltfläche passiert ist. Ziel ist es festzustelen ob es über Fensterschliessen ausgelöst wurde. Da das offensichtlich nicht geht könnten wir alle anderen Auslöser prüfen. Wenn es nicht einer von denen ist, dann war es der Fensterschliessen. Nur dann hätten wir viel zu tun: prüfen auf Datensatzmarkierer, auf Tastenkombi usw...

 

Hallo JPA.

Nein, wenn das Ereignis nicht durch die Ok-Schaltfläche ausgelöst wurde, wird die Benutzerin aufgefordert sich zwischen speichern, verwerfen, bearbeiten zu entscheiden und die Datenänderungen werden im Formular hervorgehoben, was ihr die Entscheidung erleichtert.

Die Frage ist m.E. mittlerweile beantwortet. Es gibt keine direkte Möglichkeit.

Genauso ist es.
Es ist aber nicht klar ob wirklich alle Auslöser identifizierbar sind.
Das Fenster kann auch durch Beenden von Access oder Runterfahren des Rechners geschlossen werden.

Darum stellt sich die Frage: Wozu muss der eigentliche Auslöser für das Schließen identifiziert werden!

Und genau die von dir genannte Anforderung: verhindern, dass ein Schließen zu einer ungewollten Datensatzänderung führt, ist in meinem Beispiel einfach realisiert.

Frithjof

 

\@nouba
vielen dank für dein programmcode.
Die Zeilen "Private Declare PtrSafe Function" sind bei mir rot.

Wenn ich den Code richtig interpretiere, wird die Fensterschliess-Schaltfläche ausgendet/deaktiviert wenn der Datensatz im Form dirty ist, oder?

Ist auf jedenfall eine Problemvermeidung strategie, danke.

VG

 

https://msdn.microsoft.com/de-de/lib...ffice.14).aspx


Edit:
Die Office Version muss longptr unterstützen, damit du den Code 1:1 verwenden kannst.
Ich dacht 2010 hat das bereits.