Discussion:
Msgbox schließen
(zu alt für eine Antwort)
unknown
2007-12-07 10:53:50 UTC
Permalink
Hallo NG,

kann mir jemand den Trick verraten, wie ich einen Benutzer aus der
Datenbank rausschmeiße (bzw. dessen FE schließe), wenn bei dem gerade eine
Msgbox aktiv ist?

AXP/03/07

Danke!
--
Grüßle vom Bodensee
Jörg Ostendorp

Access-FAQ: www.donkarl.com
Sascha Trowitzsch
2007-12-07 12:25:27 UTC
Permalink
Hi Jörg,

"Jörg Ostendorp" <"Ostendorp(punkt)mpda(at)ecodatadesign(punkt)de"> schrieb im
Post by unknown
Hallo NG,
kann mir jemand den Trick verraten, wie ich einen Benutzer aus der
Datenbank rausschmeiße (bzw. dessen FE schließe), wenn bei dem gerade eine
Msgbox aktiv ist?
AXP/03/07
Wenn *DU* das nicht beantworten kannst, wer dann? ;-)

Ich hab's gerade per Automation und Application.Quit versucht:
Access schließt sich, aber die Msgbox bleibt offen.
Tja, VBA ist nunmal noch aktiv, bzw. wartet auf die Beendigung der Msgbox. Davor
geht nichts. Modal ist modal.
Man könnte den Prozess wohl bloß killen, aber das ist es sicher nicht, was du
möchtest.
Bliebe die einzige Lösung, von einem anderen Prozess aus das
Msgbox-#32770-Fenster zu verhandlen und den Button OK per SendMessage zu
klicken.
Über Automation oder aus der DB selbst heraus fällt mir nix ein.

Ciao, Sascha
André Minhorst
2007-12-07 12:59:49 UTC
Permalink
Hi,
Post by Sascha Trowitzsch
"Jörg Ostendorp" <"Ostendorp(punkt)mpda(at)ecodatadesign(punkt)de"> schrieb im
Post by unknown
kann mir jemand den Trick verraten, wie ich einen Benutzer aus der
Datenbank rausschmeiße (bzw. dessen FE schließe), wenn bei dem gerade eine
Msgbox aktiv ist?
AXP/03/07
Access schließt sich, aber die Msgbox bleibt offen.
Tja, VBA ist nunmal noch aktiv, bzw. wartet auf die Beendigung der Msgbox. Davor
geht nichts. Modal ist modal.
Man könnte den Prozess wohl bloß killen, aber das ist es sicher nicht, was du
möchtest.
Bliebe die einzige Lösung, von einem anderen Prozess aus das
Msgbox-#32770-Fenster zu verhandlen und den Button OK per SendMessage zu
klicken.
Über Automation oder aus der DB selbst heraus fällt mir nix ein.
Aus der Datenbank heraus: Formular mit Timer, dass das Meldungsfenster
unter bestimmten Bedingungen, die regelmäßig geprüft werden, mit
SendKeys killt. Probleme sind zwei:

1. Bedingung setzen: DB soll geschlossen werden, setze irgendeine
Boolean-Variable innerhalb der Datenbank auf True. Das müsste aber von
außerhalb passieren, weil Du die Datenbank ja wohl auch von außerhalb
schließen willst. Vielleicht eine öffentliche Variable des Formulars mit
dem Timer?

2. Meldungsfenster identifizieren: Bei der testgetriebenen Entwicklung
habe ich vor dem Öffnen eines Meldungsfensters den Fenstertitel in eine
globale Variable geschrieben. Den lese ich dann aus, identifiziere das
Fenster mit FindWindow, hole es mit SetForegroundWindow nach vorne und
setze dann Sendkeys ab. Interessant wäre bei Dir wahrscheinlich, die
Taste des Meldungsfensters zu treffen, die keinen Schaden anrichtet. Das
kann man je Meldungsfenster vielleicht auch noch vor dem Öffnen in eine
globale Variable schreiben und dann per Sendkeys erst den Fokus auf die
richtige Schaltfläche setzen und dann anklicken. Bedeutet zwar mehr
Programmieraufwand, wäre dann aber so zuverlässig, wie Vorgänge mit
SendKeys eben sein können. ;-)

Ciao
André
--
http://www.access-entwicklerbuch.de
http://www.access-im-unternehmen.de
Sascha Trowitzsch
2007-12-07 13:23:03 UTC
Permalink
Hi,

(Kapitel schon fertig, oder wat??)
Hi,
Post by Sascha Trowitzsch
"Jörg Ostendorp" <"Ostendorp(punkt)mpda(at)ecodatadesign(punkt)de"> schrieb
Post by unknown
kann mir jemand den Trick verraten, wie ich einen Benutzer aus der
Datenbank rausschmeiße (bzw. dessen FE schließe), wenn bei dem gerade eine
Msgbox aktiv ist?
AXP/03/07
Access schließt sich, aber die Msgbox bleibt offen.
Tja, VBA ist nunmal noch aktiv, bzw. wartet auf die Beendigung der Msgbox.
Davor geht nichts. Modal ist modal.
Man könnte den Prozess wohl bloß killen, aber das ist es sicher nicht, was du
möchtest.
Bliebe die einzige Lösung, von einem anderen Prozess aus das
Msgbox-#32770-Fenster zu verhandlen und den Button OK per SendMessage zu
klicken.
Über Automation oder aus der DB selbst heraus fällt mir nix ein.
[...] Interessant wäre bei Dir wahrscheinlich, die Taste des Meldungsfensters
zu treffen, die keinen Schaden anrichtet. Das kann man je Meldungsfenster
vielleicht auch noch vor dem Öffnen in eine globale Variable schreiben und
dann per Sendkeys erst den Fokus auf die richtige Schaltfläche setzen und dann
anklicken. Bedeutet zwar mehr Programmieraufwand, wäre dann aber so
zuverlässig, wie Vorgänge mit SendKeys eben sein können. ;-)
Drum habe ich ja SendMessage erwähnt. ;-)
Dann ist Sendkey nicht mehr notwendig.
Einfach BM_CLICK an den OK-Button senden.

Ciao, Sascha
unknown
2007-12-07 14:51:40 UTC
Permalink
Hallo Sascha und André,

erstmal artigst Danke für die Antworten!
Post by André Minhorst
Post by Sascha Trowitzsch
Post by unknown
kann mir jemand den Trick verraten, wie ich einen Benutzer aus der
Datenbank rausschmeiße (bzw. dessen FE schließe), wenn bei dem gerade eine
Msgbox aktiv ist?
AXP/03/07
Access schließt sich, aber die Msgbox bleibt offen.
Tja, VBA ist nunmal noch aktiv, bzw. wartet auf die Beendigung der Msgbox. Davor
geht nichts. Modal ist modal.
Man könnte den Prozess wohl bloß killen, aber das ist es sicher nicht, was du
möchtest.
Bliebe die einzige Lösung, von einem anderen Prozess aus das
Msgbox-#32770-Fenster zu verhandlen und den Button OK per SendMessage zu
klicken.
Über Automation oder aus der DB selbst heraus fällt mir nix ein.
Aus der Datenbank heraus: Formular mit Timer, dass das Meldungsfenster
unter bestimmten Bedingungen, die regelmäßig geprüft werden, mit
1. Bedingung setzen: DB soll geschlossen werden, setze irgendeine
Boolean-Variable innerhalb der Datenbank auf True. Das müsste aber von
außerhalb passieren, weil Du die Datenbank ja wohl auch von außerhalb
schließen willst. Vielleicht eine öffentliche Variable des Formulars mit
dem Timer?
Das passiert über einen Tabelleneintrag im Backend, den der Admin
entsprechend für Wartungsarbeiten setzen kann. Wird dann von den FEs über
einen Timer abgefragt.
Post by André Minhorst
2. Meldungsfenster identifizieren: Bei der testgetriebenen Entwicklung
habe ich vor dem Öffnen eines Meldungsfensters den Fenstertitel in eine
globale Variable geschrieben. Den lese ich dann aus, identifiziere das
Fenster mit FindWindow, hole es mit SetForegroundWindow nach vorne und
setze dann Sendkeys ab. Interessant wäre bei Dir wahrscheinlich, die
Taste des Meldungsfensters zu treffen, die keinen Schaden anrichtet. Das
kann man je Meldungsfenster vielleicht auch noch vor dem Öffnen in eine
globale Variable schreiben und dann per Sendkeys erst den Fokus auf die
richtige Schaltfläche setzen und dann anklicken. Bedeutet zwar mehr
Programmieraufwand, wäre dann aber so zuverlässig, wie Vorgänge mit
SendKeys eben sein können. ;-)
Mit dem Fenstertitel versagt es bei mir, da unterschiedliche Dialoge mit
unterschiedlichen Titeln offen sein können (Msgbox, Inputbox, FileDialog
etc.). Glücklicherweise gehören sie alle zur Klasse #32770 und zudem
exisitieren accessseitig keine weiteren derartiger Fenster.

Habe es jetzt vorerst so gelöst, daß ich vom Startformular ggf. ein
Meldungsformular aufrufe, von wo aus nach Ablauf einer Gnadenfrist für den
Nutzer die Close-Prozedur gestartet wird.

Dadrin werden zunächst alle Fenster mit EnumThreadWindows durchgelaufen und
ein SendMessage WM_Close auf die Klassen #32770 abgesetzt. Das funktioniert
schonmal für die Windows-Dialoge, die in der Regel ja unterschiedliche
Fenstertitel haben.

War das nicht erfolgreich (IsWindow) handelt es sich um eine Msg- oder
Inputbox.
In dem Fall durchlaufe ich nochmal deren ChildWindows, um den richtigen
Button zu erwischen, auf den dann ein Sendmessage BM_Click abgesetzt werden
kann. Diesen wiederum identifiziere ich über die ID (GetWindowLong).
Man kann das wie vorgeschlagen natürlich sicherer über eine Variable lösen,
aber ich habe deutlich mehr als 500 Messageboxen und am Montag
Abgabetermin. Ggf. wäre aber eh der konsequente Einsatz eigener
Message-Formulare einfacher.

Wie auch immer das Finden des richtigen Buttons ist wirklich der
Knackpunkt, da hierdurch ja eventuell weitere Aktionen angeleiert werden.
Glücklicherweise ist es bei mir so, daß alle Buttons, auf die geklickt
werden muß, etweder OK, Abbrechen oder Nein sind. Diese haben immer die IDs
2, 3(2) und 7 (hoffentlich ;-))

Ein weiteres Problem war noch das Schließen der Applikation. Ein
Application.Quit läßt den Prozess offen. Ein
Application.Closecurrentdatabase schließt aber zumindest die aktuelle
Datenbank, naja.
--
Grüßle vom Bodensee
Jörg Ostendorp

Access-FAQ: www.donkarl.com
Jens Schilling
2007-12-07 13:29:25 UTC
Permalink
Hallo, Jörg
Post by unknown
Hallo NG,
kann mir jemand den Trick verraten, wie ich einen Benutzer aus der
Datenbank rausschmeiße (bzw. dessen FE schließe), wenn bei dem gerade
eine Msgbox aktiv ist?
Wäre eine zeitgesteuerte Msgbox mit Windows Script eine Alternative ?
--
Gruss
Jens
______________________________
FAQ: http://www.donkarl.com
unknown
2007-12-07 14:44:04 UTC
Permalink
Hallo Jens,
Post by Jens Schilling
Post by unknown
kann mir jemand den Trick verraten, wie ich einen Benutzer aus der
Datenbank rausschmeiße (bzw. dessen FE schließe), wenn bei dem gerade
eine Msgbox aktiv ist?
Wäre eine zeitgesteuerte Msgbox mit Windows Script eine Alternative ?
Danke für die Antwort! Nee, die Messageboxen sollen prinzipiell schon so
lange geöffnet bleiben, bis der Nutzer sie anklickt. Vor allem wäre aber
auch der Aufwand aktuell einfach zu hoch, das alles nochmal umzuschreiben,
sind über 500.
--
Grüßle vom Bodensee
Jörg Ostendorp

Access-FAQ: www.donkarl.com
Sascha Trowitzsch
2007-12-07 16:07:39 UTC
Permalink
Hi Jörg,

"Jörg Ostendorp" <"Ostendorp(punkt)mpda(at)ecodatadesign(punkt)de"> schrieb im
Post by unknown
Hallo Jens,
Post by Jens Schilling
Post by unknown
kann mir jemand den Trick verraten, wie ich einen Benutzer aus der
Datenbank rausschmeiße (bzw. dessen FE schließe), wenn bei dem gerade
eine Msgbox aktiv ist?
Wäre eine zeitgesteuerte Msgbox mit Windows Script eine Alternative ?
Danke für die Antwort! Nee, die Messageboxen sollen prinzipiell schon so
lange geöffnet bleiben, bis der Nutzer sie anklickt. Vor allem wäre aber
auch der Aufwand aktuell einfach zu hoch, das alles nochmal umzuschreiben,
sind über 500.
Wieso? Bau doch einfach eine benutzerdefinierte Funktion Msgbox() in dein
VBA-Projekt. Dann musst du weiter nix ändern, weil die benutzerdefinierten
Funktionen Vorrang vor den eingebauten haben.
(Ich hätte eine selbstgebaute Formular-Msgbox da, ist aber A2007.) In eine
selbstgebaute Msgbox könntest du zudem einen Timer einbauen, der deine
Shutdown-Variable abfragt und sich im Fall der Fälle dann automatisch schließt.
Das könnte in 2 Stunden erledigt sein.

Ciao, Sascha
unknown
2007-12-07 18:46:23 UTC
Permalink
Hallo Sascha,
Post by Sascha Trowitzsch
Post by unknown
Post by Jens Schilling
Post by unknown
kann mir jemand den Trick verraten, wie ich einen Benutzer aus der
Datenbank rausschmeiße (bzw. dessen FE schließe), wenn bei dem gerade
eine Msgbox aktiv ist?
Wäre eine zeitgesteuerte Msgbox mit Windows Script eine Alternative ?
Danke für die Antwort! Nee, die Messageboxen sollen prinzipiell schon so
lange geöffnet bleiben, bis der Nutzer sie anklickt. Vor allem wäre aber
auch der Aufwand aktuell einfach zu hoch, das alles nochmal umzuschreiben,
sind über 500.
Wieso? Bau doch einfach eine benutzerdefinierte Funktion Msgbox() in dein
VBA-Projekt. Dann musst du weiter nix ändern, weil die benutzerdefinierten
Funktionen Vorrang vor den eingebauten haben.
Ja, wieso eigentlich nicht? Ich glaube, weil ich, ohne groß drüber
nachzudenken, davon ausgegangen bin, daß benutzerdefinierte Funktionen
nicht so heißen dürfen/sollten, wie eingebaute.
Wobei das eigentlich eh Schnuppe ist, ich kann den Aufruf als solchen ja
auch einfach per Find and Replace umbenennen solange ich in der eigenen
Funktion mit den gleichen Parametern/Enums arbeite.
Post by Sascha Trowitzsch
(Ich hätte eine selbstgebaute Formular-Msgbox da, ist aber A2007.) In eine
selbstgebaute Msgbox könntest du zudem einen Timer einbauen, der deine
Shutdown-Variable abfragt und sich im Fall der Fälle dann automatisch schließt.
Das könnte in 2 Stunden erledigt sein.
Mache ich fürs nächste Update im Januar. Momentan mag ich nichts mehr
ändern. Habe eh noch kräftig zu testen und mit dem Setup zu kämpfen.
--
Grüßle vom Bodensee
Jörg Ostendorp

Access-FAQ: www.donkarl.com
Mark Doerbandt
2007-12-09 19:35:28 UTC
Permalink
Hallo, Jörg,
Post by unknown
davon ausgegangen bin, daß benutzerdefinierte Funktionen
nicht so heißen dürfen/sollten, wie eingebaute.
hast wohl bei der AEK nicht gut zueghoert!? ;-)

Gruss - Mark
unknown
2007-12-10 21:59:07 UTC
Permalink
Hallo Mark,
Post by Mark Doerbandt
hast wohl bei der AEK nicht gut zueghoert!? ;-)
Wie? Was?
Hab ich nicht aufgepasst?

Keine Zeit, keine Zeit...
--
Stress-Grüßle vom Bodensee
Jörg Ostendorp

Access-FAQ: www.donkarl.com
Henry Habermacher
2007-12-10 03:01:47 UTC
Permalink
Hallo Jörg

"Jörg Ostendorp" <"Ostendorp(punkt)mpda(at)ecodatadesign(punkt)de"> wrote in
Post by unknown
Post by Sascha Trowitzsch
Wieso? Bau doch einfach eine benutzerdefinierte Funktion Msgbox() in dein
VBA-Projekt. Dann musst du weiter nix ändern, weil die
benutzerdefinierten
Funktionen Vorrang vor den eingebauten haben.
Ja, wieso eigentlich nicht? Ich glaube, weil ich, ohne groß drüber
nachzudenken, davon ausgegangen bin, daß benutzerdefinierte Funktionen
nicht so heißen dürfen/sollten, wie eingebaute.
Wobei das eigentlich eh Schnuppe ist, ich kann den Aufruf als solchen ja
auch einfach per Find and Replace umbenennen solange ich in der eigenen
Funktion mit den gleichen Parametern/Enums arbeite.
Find and Replace ist überflüssig. Leg' einfach eine Public Function mit dem
gleichen Namen an. Ich verwende das seit Jahren ohne irgend ein Problem,
seit die MsgBox() standardmässig nicht mehr formattiert daher kommt (also
"@Ü***@teil1@teil2") nicht migrieren zu müssen.

Ich glaube fast, dazu steht sogar was in der FAQ.

Gruss
Henry
André Minhorst
2007-12-10 13:21:44 UTC
Permalink
Hi Henry,
[...] Leg' einfach eine Public Function mit
dem gleichen Namen an. [...]
Ich glaube fast, dazu steht sogar was in der FAQ.
ich glaube sogar, dass dazu schon was in diesem Thread steht ... ;-)

Ciao
André
--
http://www.access-entwicklerbuch.de
http://www.access-im-unternehmen.de
Loading...