Hallo,
Ich würde gerne
mit einer Ereignisprozedur die Datenbank speichern und anschließend Access schließen.
Leider bin ich nicht fit genug um das ohne eure Hilfe zusetzen.
Im Generator habe ich keinen Vorschlag gefunden und in Netz auch noch nicht.
Kann mir jemand von euch mir helfen?
LG Wilfried
Hallo Wilfried,
aus einer Ereignisprozedur direkt Application.Quit aufzurufen halte ich nicht für sauber. Die Ereignisprozedur sollte ordnungsgemäß beendet werden. Deshalb verwende ich dafür folgenden Code in einem Modul und rufe als letztes in der Ereignisprozedur SendAppClose auf.
Private Declare PtrSafe Function PostMessage Lib "user32" _
Alias "PostMessageA" (_
ByVal hwnd As LongPtr, ByVal wMsg As Long, _
ByVal wParam As LongPtr, ByVal lParam As LongPtr) As Long
Sub SendAppClose
Const WM_CLOSE = &H10
PostMessage hWndAccessApp, WM_CLOSE, 0&, 0&
End Sub
Das mit dem Speichern mußt du aber selber organisieren.
Gruß Knobbi38
Danke, probir ich heute Abend hleich aus
Zitat von: knobbi38 am Februar 06, 2025, 11:10:25aus einer Ereignisprozedur direkt Application.Quit aufzurufen halte ich nicht für sauber
Weil?
So eine Meinung höre ich zum ersten Mal und sie hört sich erstmal ziemlich schräg an.
Grundsätzlich folgt doch jeder Code einer Ereignisprozedur.
Wieso ist das schräg? Weißt du, was beim Application.Quit intern in Access passiert und ob das Windows Event noch richtig abgeschlossen wird? Kann ja sein, aber da gehe ich auf Nummer sicher und poste einfach ein WM_Close, so als ob jemand oben Links den Close-Button vom Anwendungsfenster klickt - ist ja nicht verboten und musst du ja auch nicht machen.
Gruß Knobbi38
Hallo,
also ich würde auch davon ausgehen, daß es bei "Application.Quit" keinerlei Probleme gibt, egal von wo man das aufruft. Denn Access bekommt so oder so die Message, sich zu beenden und muß dann für das Schließen aller Ressourcen sorgen (und mit ziemlich hoher Wahrscheinlichkeit ruft Access dann selbst seine Quit-Methode auf).
Daß man dabei wenigstens vorher selbst noch aufräumt, sowas wie extern gestartete Anwendungen wie Word/Excel-Automationsobjekte usw., sollte soweit klar sein. Diese würden sicherlich auch nicht durch eine Windows-API-Funktion automatisch geschlossen werden.
Den Umstand mit API würde ich nicht machen. Da sehe ich keinerlei Vorteile, eher Nachteile wie falsche Deklaration oder falscher Umgang mit Parametern, 32/64Bit-Deklarationen usw. APIs würde ich immer nur einsetzen, wenn es gar keine andere Möglichkeit gibt, etwas zu erreichen.
"Datenbank speichern" ist allerdings keine Tätigkeit, die man durchführen muß, um nochmal auf das Eingangsposting zu kommen. Lediglich der gerade bearbeitete Datensatz muß gespeichert werden in den jeweils offenen Formularen. Aber auch das erledigt Access automatisch beim Beenden oder Schließen von Formularen.
Gruß
Christian
Hallo,
nun, der Unterschied ist der, daß bei Application.Quit augenblicklich aus der Prozedur herausgesprungen wird, alle folgenden Codezeilen werden nicht mehr ausgeführt. Mit Postmessage WM_CLOSE wird die Close-Message an das Ende der MessageQueue angefügt und das führt dazu, daß noch ausstehende Messages in der Queue davor noch ausgeführt werden, bevor Access ordnungsgemäß wie beim Klick auf das Anwendungsfenster beendet wird.
Praktisch bedeutet das, daß die nachfolgenden Codezeilen in der Ereignisprozedur i.d.R noch ausgeführt werden. Es ist also kein Nachteil, eher ein Vorteil, hier einen API Aufruf zu verwenden.
@Bitsqueezer API Aufrufe sind doch per se nicht schlecht bzw. von Nachteil, man muß sie nur richtig anwenden und sind außerdem in VBA weit verbreitet und erlaubt.
Grüße
Knobbi38
Hallo,
nein, per se schlecht sind sie natürlich nicht, das wollte ich damit auch nicht sagen.
Schließlich arbeiten "unter der Haube" so ziemlich alle Anwendungen damit, sonst bräuchte man kein OS... :)
Lediglich, daß deren Anwendung mehr Sorgfalt erfordert. Generell ist es halt einfacher, ohne API zu arbeiten, solange es andere Methoden dazu gibt.
Nach "Application.Quit" sollten wohl keine Codezeilen mehr stehen.. ;)
Wie gesagt, vorher selbst aufräumen muß man in jedem Fall. Das ändert auch ein API-Aufruf nicht.
Ich wage aber stark zu bezweifeln, daß "Application.Quit" nicht zumindest die "normalen" Access-internen Prozesse vorher beendet, z.B. in einem geöffneten Formular, daß Dirty ist, erst den Datensatz zu speichern.
Und welche sonstigen Messages fehlen Dir dann noch? Wenn Application.Quit zu Problemen führen würde, hätte man das in den letzten 20 Jahren sicher bemerkt.
Gruß
Christian
@Bitsqueezer Es kommt wie immer auf den Kontext an. Wenn z.B. zur Programmsteuerung Klassen eingesetzt werden, ist es nicht immer wünschenswert, wenn dort in einer untergeordneten Klasse ein Application.Quit eingesetzt wird und alles abrupt terminiert wird. Da bietet die Lösung mit Postmessage eine bessere Alternative an. Da sie sonst keine Nachteile gegenüber Quit hat, kann man sie eigentlich gleich überall verwenden.
Grüße
Ulrich