Office: (Office 2000) Anwendung von Taskkill unter VBA

Hallo Sascha,

habe Deinen Code jetzt im Code des Access-Windows eingebaut und beim Schließen des Fensters die Sub ClickyesShutDown aufgerufen.
Es passiert jedoch garnichts. Was mache ich falsch bzw. wie wird Deinen zur Verfügung gestellter Code eingebaut?

 

Komisch. Gestern hat's irgendwie noch funktioniert; jetzt bei mir auch nicht mehr. Keine Ahnung, was da war...
Mit dem Code sollte es aber wirklich gehen:
Code:

Ciao, Sascha

 

Hallo Sascha,
in der ersten Variante hat nur dies gefehlt:
Public Const WM_CLOSE = &H10

 

Wieso, die Konstante ist doch oben im Code drin?
Bei mir geht das nicht mehr, obwohl ich es gestern mehrmals getestet hatte. Eigenartig...

Ciao, Sascha

 

oh sorry, dann hat die Zeile nur bei mir gefehlt.
Mit der Deklaration der Konstanten geht's bei mir.
Allerdings übergebe ich nicht lpClassName, sondern lpWindowName als String.

 

Das Handle findet er auch bei mir mit Classname.
Aber der Prozess reagiert nicht auf das WM_Close obwohl die Rückgabe von SendMessage 0 ist.
Naja, egal.

Ciao, Sascha

 

Hallo Sascha,

vielen Dank, mit der neuen Version funktioniert es.
Da ich sehr wenig Ahnung von dem habe was Du mir jetzt zur Verfügung gestellt hast, wäre es nett, wenn Du mir zum besseren Verständnis den Code grob erläutern könntest.
Habe nicht gern etwas in der DB, von dem ich zwar weiß das es funktioniert, aber nicht genau wie!!

 

Ok...
(Schön eigentlich, dass mal jemand nachfragt und verstehen will, anstatt nur Copy&Paste zu betreiben... *wink.gif* )

hwnd = FindWindow("EXCLICKYES_WND", 0&)

...FindWindow ermittelt ein beliebiges Fenster anhand seines Klassennamens. Bei ClickYes ist das die Klasse "EXCLICK_WND". Zurückgegeben wird dann von der Funktion ein sog. Handle, das ein Fenster unter Windows eindeutig identifiziert. Das "Fenster" von ClickYes ist übrigens das Icon im Tray.

If hwnd = 0 Then Exit Sub

...Falls kein Handle ermittelt werden (=0) konnte: Aussieg aus der Prozedur.

ret = GetWindowThreadProcessId(hwnd, pid)

... Mit dieser API-Funktion kann man zu einem Fensterhandle (hwnd) die ID des zugehörigen Prozesses ermitteln. Im Prinzip: Prozess = Exe.
Jeder unter Windows laufende Prozess hat eine ID. (Siehe Taskmanager, Spalte PID) In Der Funktion wird dabei die als Parameter übergebene Variable pid mit dem Wert gefüllt.

tid = OpenProcess(1&, 0, pid)

...Um auf den Prozess über sein ID zugreifen zu können, muss man quasi von Windows dafür die Erlaubnis bekommen. OpenProcess() öffnet nicht etwa eine Prozess, sondern gewährt Zugriff auf ihn. Parameter 1& besagt, dass man die spezielle Berechtigung zum Beednen des Prozesses haben möchte (entspricht API-Konstante PROCESS_TERMINATE).
tid enthält anschließend das gültige Prozess-Handle.
Bei eingeschränkten Benutzerrechten kann es sein, dass die Funkton in tid keinen Wert zurückgibt. Dann funktioniert das Ganze nicht.

ret = TerminateProcess(tid, 0&)

... TerminateProcess() killt den über tid übergebenen Prozess.
Wenn es geklappt hat, dann steht in ret ein Wert ungleich 0. Bei 0 ist was schiefgelaufen. Genauere Erläuterung der Funktion:
"TerminateProcess initiates termination and returns immediately. This stops execution of all threads within the process and requests cancellation of all pending I/O. The terminated process cannot exit until all pending I/O has been completed or canceled."

Ciao, Sascha

 

Vielen Dank für Deine Erläuterungen. Wenn auch nicht alles direkt nachzuvollziehen war, sieht die Sache doch schon etwas klarer aus.

Zu Deiner Anmerkung von wegen Nachfragen ist gut nur soviel;

Wenn hier im Forum von uns sogenannten Laien mal Fragen gestellt werden, die audfgrund von Hilfeseiten o.ä. nicht verstanden wurden, werden aber auch oft genug, speziell auch von Dir, Verweise auf irgendwelche anderen Links gegeben, mit denen man dann genau soviel anfangen kann wie mit der Hilfe selbst.

Fazit daraus: Man fragt einfach nicht mehr nach sondern nimmt das was man bekommen kann bevor man garnicht mehr an irgendeine Hilfe (die man versteht) kommt. Also besser Copy&Paste als nichts!

Nichts für ungut, hoffe Du nimmst diese Kritik nicht persönlich, auch wenn ich Dir direkt hier angesprochen habe.*wink.gif*

 

Also, ich glaube, dass *ich* eigentlich gar nicht so viel linke, sondern eher schreibe - sonst hätte ich, ganz bescheiden *wink.gif* , den MVP-Titel nie bekommen.
Egal...
Aber mir ist auch nicht klar, wie du dir's anders vorstellen könntest:
Man kann ja nicht a priori davon ausgehen, dass ein User mit den Infos eines Links nichts anfangen kann und den Sachverhalt dort vorsorglich zusätzlich erläutern. Sollte das der Fall sein, dann ist schon noch eine weitere Nachfrage angebracht, dass man mit den entspr. Infos nicht zurecht kommt.
Auch wenn aus der Art einer Problembeschreibung und der folgenden Diskussion oft hervorgeht, wie es um die Skills eines Fragestellers bestellt ist, kann man nicht immer genau einschätzen, auf welchem "Niveau" man eine Antwort geben soll. Wenn ich also einen Link anbringe, dann gehe ich zunächst in gutem Glauben davon aus, dass die Infos dort verstanden werden können und einen Mehrwert zum bisher in einem Thread Gesagten bringen. Schließlich muss ja das Rad nicht immer neu erfunden werden und das Meiste wurde bereits irgendwo im Netz zu jeglichem Thema gesagt.

Aber du sprichts da auch was Grundsätzliches an:
Ich habe schon oft mit anderen Leuten, bei Stammtischen oder sonst wo, darüber diskutiert, was denn die beste Art zu antworten wäre. Viele stehen auf dem Standpunkt, nur das Allernotwendigste and Infos zu geben, um dem Fragesteller auf die Spünge zu helfen. Dahinter steht das pädagogische Konzept, dem User lediglich Orientierung zu geben und ihn die eigentliche Arbeit, ob coden oder Erkenntns, selbst machen zu lassen, anstatt ihm eine Lösung vorzukauen, die er nur ansatzweise versteht. Damit ist erstens einigermaßen sichergestellt, dass er nicht "über seine Verhältnisse" entwickelt, und zweitens, dass er nicht mit Dingen konfrontiert wird, für die er eigentlich noch nicht reif ist.

Ich sehe das nicht ganz so. Deshalb hab ich den Code oben auch erläutert. Ich hätte gut und gerne auch sagen können: Tja, Leute, ladet euch mal das Win-Platform-SDK herunter, schmökert wochenlang darin rum, kauft euch ein Buch zu API-Programmierung. Und das wäre nicht ganz falsch gewesen. Denn API-Programmierung ist nunmal etwas, was gerade für einen VBA-Programmierer recht weit entfernt ist und doch erhebliche Kenntnisse erfordert.
Wenn ich den Code dennoch zu dokumentieren versucht habe, dann deshalb, weil ich hoffe, dass das evtl. ein Anreiz sein kann, sich mit der Materie etwas mehr auseinander zu setzen. Immerhin zeigt der Code ja, dass man mit ihm auf den Aufruf einer externen Exe verzichten kann, was ein Plus pro API-Programmierung darstellen sollte. Also der Versuch, zu verdeutlichen, dass man den Horizont erweitern und über den Tellerrand von VBA hinausschauen kann.

Gruß, Sascha

 

\@Sascha: Noch nachträglich meinen herzlichen Glückwunsch zum MVP. Ich war gerade mal auf deinem Profil. Es ist schön, zum Namen ein Bild zu haben.

Da bei mir auch die SendMessage-Methode funktioniert, habe ich beide Methoden mal miteinander verglichen - beim Schließen einer Access-DB mit noch ungesicherten Daten im Formular.
Die TerminateProcess-Methode macht die Anwendung knallhart zu. Daten werden nicht gespeichert.
Die SendMessage-Methode ist sanfter und entspricht eher dem Klicken auf den Schließen-Button des Anwendungsfensters. Die Daten werden gespeichert und sogar die im Form_Close-Ereignis stehenden Anweisungen werden ausgeführt (was zum Freeze führt, wenn dort der Aufruf eines neuen Formular drinsteht.)
Dies für diejenigen, die es interessiert.

Nun zu meinem Problem. Evtl. wäre ein neues Thema besser gewesen. Aber ich will mich an Saschas oben geposteten Code zum Finden des Handles anlehnen.
Es geht um das Finden einer geöffneten MDB (MDB-1), ausgehend von einer gleichfalls laufenden MDB (MDB-2).
Dabei geht es mir lediglich um die Information, ob MDB-1 schon geöffnet ist. Das Ergebnis hwnd 0 ist also schon ausreichend.
Beides sind ja Access-Applikationen. Wie lautet der Klassenname. Auch gleich?
Wie lautet überhaupt der Klassenname einer geöffneten MDB? Nur irgendwass mit ...ACCESS..., oder ist der Dateiname auch mit drin.
Sind die Klassen irgendwo in der Registry aufgeführt?

Ich habe mangels Unkenntnis der Klasse meine Tests statt dessen mit dem Argument lpWindowName gemacht.
hwnd = FindWindow(0&, "FensterName")
Bei einer MDB ist FensterName = ApplicationTitle & " - [" & CaptionVonAktivemFenster & "]"
Das bedeutet, man muß wissen, welches Fenster im Vordergrund liegt (aúßer Popups). Und daß ist aus Sicht der anderen MDB nicht so einfach, oder?
Natürlich könnte man alle möglichen Formulare durchtesten (die sind bekannt), und warten, bis der Handle 0 ist. Dies halte ich jedoch nicht für optimal.

Daher meine Frage:
Gibt es eine Möglichkeit, per API die Namensliste aller Fenster durchzugehen und mit einem "Like" den richtige Handle zu finden? Ungefähr so:
For each Window

 

Danke, Frank, zum Glückwunsch.

Zum Klassennamen von Fenstern: Nein, da gibt es keine Liste drüber. Jeder Programmierer kann seinen Fenstern im Prinzip einen eigenen Klassennamen geben. Es gibt zwar unter Window vordefinierte Fensterklassen wie "STATIC", "BUTTON", "COMBOBOX","EDIT", "WC_LISTVIEW" etc. mit bestimmten Eigenschaften, aber alle Applikationsfensterklassen haben spezielle Namen. Die lassen sich mit einem Tool wie WinCheat ermitteln ( http://alinconstantin.dtdns.net/Down...at/Default.htm ). Man zieht den Cursor aus dem Tool über ein Fenster und es zeigt dazu diverse Eigenschaften desselben an.
Der Klassenname des Access-Hauptfensters lautet immer "OMain".
Mehrere geöffnete Access-Anwendungen lassen sich also nicht allein über den Klassennamen ermitteln - im Unterschied zu ClickYes, von dem immer nur eine Instanz offen sein kann. Also braucht man zusätzlich den Titel des Fensters, der sich so ähnlich bildet, wie von Frank beschrieben. Aber leider ohne Garantie. Es ist unter jeder Version von Access anders. Meist steckt im Titel auch noch das Format der Datenbank. FindWindow reicht also grundsätzlich nicht aus.

Man kann alle Top-Windows - quasi Hauptfenster, die nicht Kindfenster eines anderen Fensters sind -, mit der API-Funktion EnumWindows durchlaufen. Nachfolgend wäre die Prozedur FindAnAccessDatabase aufzurufen:

Der Code könnte so aussehen:
Code:

EnumWindows weist an, dass alle Fenster in einer (nicht sichtbaren) Schleife durchlaufen werden und für jedes die Funktion EnumWinProc aufgerufen werden soll.
Die einzelnen Handles konnen in dieser Funktion dann ausgewertet werden.
Windows kennt übrigens VBA-Funktionen ja nicht und deshalb muss man der API-Funktion über den AddressOf-Operator mitteilen, wo sie zu finden sind.

In der Enumerationsprozedur wird dann einmal mit GetWindowText der Fenstertitel aller Fenster ermittelt und zum anderen die Klassennamen mit GetClassName. Beide erwarten als Parameter jeweils ein Fensterhandle und eine Stringvariable.

In der Prozedur ist dann noch ein Vergleich dieser Strings mit Access' Klassennamen "OMain" und dem in strDB (Instr~LIKE) gespeicherten Datenbanknamen enthalten. Wenn beides zutrifft, dann wird die Enumeration beendet, indem deren Rückgabewert 0 beträgt. (Nur mit Rückgabe 1 macht sie mit anderen Fenstern weiter.)

Erst, nachdem alle Fenster enumeriert sind bzw. das korrekte Access ermittelt wurde, fährt VBA mit der Zeile hinter EnumWindows fort.
Dort steht dann in der modulweit deklarierten Variablen hwndAcc das Handle der Access-Applikation zur weitern Verwendung - z.B. KillTask wie oben mit SendMessage oder TerminatePRocess.

Die API-Deklarationen sind nicht im Code enthalten. Das ist nun wieder Pädagogik. *wink.gif* Man holt sie sich am Besten mit diesem Tool:
http://www.activevb.de/rubriken/apiv...apiviewer.html
In VB6 klinkt es sich selbständig in das Menü ein, unter VBA nicht. Tipp: MZ-Tools benutzen und die API-Viewer-Exe über deren Option "Externe Hilfsmittel" zum MZ-Tools-Menü hinzufügen. Dann hat man ihn immer schnell im Griff.

Abschließend: Die Bedeutung von API-Funktionen findet man am schnellsten in der Microsoftschen Referenz MSDN. Um etwa FindWindow erklärt zu bekommen in Google eingeben:
"FindWindow MSDN". Die erste Fundstelle sollte meist stimmen. Um Englisch wird man übrigens in punkto API-Programmierung nicht herumkommen.

Was bleibt ist noch ein Problem: Wenn zwei Instanzen der gleichen Datenbank offen sind, dann hilft der Code nicht weiter.
Dann ist noch allerlei zusätzlicher API-Code notwendig, um die beiden auseinander zu halten. Das lass ich lieber weg...

Gruß, Sascha

 

Hallo Sascha,

erst einmal vielen Dank für Deine Erläuterungen bzw. Darstellung Deines Standpunktes.

In vielen Punkten kann ich Dir sogar beipflichen. Es wird sehr wahrscheinlich schwierig sein, es jedem Recht zu machen. Manchesmal steht man als Laie wirklich wie der sprichwörtliche "Ochs vorm Berg" und man fühlt sich dann etwas hilflos und verlassen.

Aber dieses Forum ist schon Spitze und bisher jedenfalls auch das Beste, was z.Zt. im Netz als Anlaufstelle bei Problemen helfen kann.

Also nichts für ungut und nochmals vielen Dank.
Bis zum nächsten Mal (..heute ist nicht alle Tage, ich komme wieder, keine Frage).*wink.gif*

 

Hallo Sascha,
vielen Dank für die Infos und Anregungen. Alles funktioniert prächtig!