![]() |
AW: FormCloseQuery FormShowing abfrage
Zitat:
Wird der Rechner heruntergefahren, dann blockiert das Programm dieses nicht! |
AW: FormCloseQuery FormShowing abfrage
Also, mir gefällt Sir Rufos Ansatz sehr gut. Wieso sollte man auch den User damit beschäftigen jedes untergeordnete Form händisch zu schließen anstatt dies zu automatisieren und über deren Form.CloseQuery die Möglichkeit zum Speichern der Daten anzubieten.
Du, kannst ja das CloseForce noch ein wenig erweitern und eine Zeitspanne vorgeben innerhalb der ein User die Daten noch speichern kann, bevor das Schließen beim Herunterfahren erzwungen wird. Regelmäßige User werden sich für diese Automation bedanken und das egal ob sie dei MainForm schließen oder einfach den Rechner herunterfahren. |
AW: FormCloseQuery FormShowing abfrage
die frage ist dann allerdings kann ich überhaupt noch speichern wenn der rechner runtergefahren wird und ich das quasi anhalte. Den das ganze ist eine DB-Anwendung und wenn ich pech hab und der mir die netzwerkverbindung killt dann kann der user auch nicht mehr speichern.
Im Normalfall soll der User ja auch das Programm beenden bevor er den rechner runterfährt. |
AW: FormCloseQuery FormShowing abfrage
Sehr gut, Problem gelöst. Nach Sir Rufos Vorschlag wird bei Programmende der FormCloseQiery jedes Child-Forms aufgerufen und der Anwender kann somit über das Fehlende Speichern informiert werden.
Beim herunterfahrern des Rechners sollte der Anwender also ohne seine Änderungen gespeichert haben und falls er "zu faul" ist seine Anwendung zu schließen bevor er den Rechner herunterfährt, wird einfach das Programm abgeschossen/forced, um den Vorgang des Hereunterfahrens nicht zu blockieren. Noch eine entsprechende Bemerkung in die Bedienungsanleitung und fertig. |
AW: FormCloseQuery FormShowing abfrage
bedienungsanleitung hehe der war gut mein chef brauchs
so einfach wir möglich der hat garnicht die zeit ne bedienungsanleitung zu lesen ^^ Da es hier um wichtige daten geht sollte der anwender schon speichern können sonst gehen nicht gespeicherte abrechnungsdaten, Kunden bzw Personaldaten, etc verloren ist nicht ohne was da alles passieren kann wenn das programm einfach so gekillt wird. Ich hab sogar schon ne sichheit eingebaut das nicht einfach was gelöscht werden kann, zumindest nicht für immer ^^ kann quasi jeden löschvorgang rückgängig machen. Sollte mal jemand was aus versehen löschen wirds wieder hergestellt. Mfg Capa |
AW: FormCloseQuery FormShowing abfrage
Wie du auf den Event reagierst bleibt dir überlassen.
Was man definitiv nicht machen sollte, beim Abmelden der Session (Abmelden/Herunterfahren) einen Dialog aufrufen "Wollen SIe speichern?". Ist total blöde, wenn der User die Anwendung noch geöffnet hat und in der Nacht sollen Updates eingespielt werden. Darum Möglichkeit A: Schmeiß die nicht gesicherten Daten in die Tonne (der User ist halt selber schuld) Möglichkeit B: Speicher die nicht gesicherten Daten in einer Sicherungs-Datei und beim nächsten Start der Anwendung werden die Formulare wieder mit diesen Daten erstellt und der Benutzer kann dann entscheiden, was damit passieren soll. |
AW: FormCloseQuery FormShowing abfrage
mhh wenn du das so sagst tendiere ich zu A den B is ja nen riesen aufwand
und ich wollt das programm noch dieses Jahr fertig bekommen ;) Achja und Nachts sind unsere Computer alle aus. Und wir hängen "Zum Glück" nicht am Intranet dran von daher werden auch keine updates eingespielt :) wenn dann mach ich das noch von hand wenn ich vorm PC sitze. |
AW: FormCloseQuery FormShowing abfrage
Wozu dann überhaupt den ganzen Aufwand mit den FormCloseQueries, wenn Du am Ende doch nur die "Schmalspurvariante" wählst?
Wenn Du Deinen Chef im Verdacht hast, des öfteren mal einen "OSI Level 8"-Fehler zu produzieren, dann schreib doch erstmal einen Prototyp für den Einstieg und rüste die temporäre Datenspeicherung in einer späteren Iteration nach. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz