ActiveX Objekt killen (im wahrsten Sinne des Wortes)
Hallo. Ich muss in einer Anwendung ein ActiveX Objekt verwenden, dass unter Umständen ein Dialogsfenster anzeigt und die Anwendung blockiert. Das es sich dabei um eine ASP.NET Anwendung handelt kann ich natürlich niemanden abstellen um "Cancel" zu klicken. Ich habe probiert das Objekt über Marshal.FinalReleaseComObject(Object) zu killen dabei bekomme ich immer eine Exception, dass das Objekt in Benutzung sei. Kann ich es irgendwie anders totbekommen? Das muss doch machbar sein. X(
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
kannst du nicht einfach den process im task manager killen?
Original von gangmember
kannst du nicht einfach den process im task manager killen?
8o Andere wollen mit der Webanwendung auch noch arbeiten. Den Prozess zu beenden ist keine Lösung. Aber evtl. den Thread. Das wäre einen Test wert, wenn niemandem mehr was einfällt.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Ich will ja nicht wissen, was die Dialogbox so von sich gibt (bitte lizensieren sie produkt x?).
Aber im ernst: In einer Server-Anwendung hat ein Control, welches eine DialogBox öffnet NIX zu suchen.
Killen wird nicht gehen, das das Control ja im Context des Server-Prozesses läuft...
Es mag da fiese low-level-api tricks geben, aber die sollte man, wenn man nicht gerade hacker werden will für eine ernsthafte anwendung ausschliessen...
Falls es doch nicht anders geht, solltest du über eine art watchdog nachdenken, der den OK-Click simmuliert... Aber bei dem Gedanken läuft mir ein Schauer den rücken runter!
Wie wäre es damit:
Du nutzt ganz normal das Control. Wenn du dann feststellst, dass es nicht mehr reagiert (also wahrscheinlich das Dialogfenster geöffnet hat), suchst du das Fenster anhand seines Titels und sendest ihm die Nachricht für Fenster schliessen.
Alles was du dafür brauchst, ist die Fenster-Klasse und der Titel.
Dies kannst du alles mit Spy++ herausfinden.
(Wenn das ActiveX-Fenster offen ist Spy++ starten, dann im Menü Spy / Find Window..., das Zielkreuz auf die Titelleiste des ActiveX-Fensters ziehen und loslassen, bei Class steht dann die Fensterklasse, bei Caption der Name)
Dann nur noch:
public const int WM_SYSCOMMAND = 0x0112; // Code für System Kommando
public const int SC_CLOSE = 0xF060; // Code für Fenster schliessen
[DllImport("user32.dll")]
public static extern int FindWindow(
string lpClassName, // Fensterklasse
string lpWindowName // Fenstername
);
[DllImport("user32.dll")]
public static extern int SendMessage(
int hWnd, // Fensterhandle
uint Msg, // Nachricht
int wParam, // erster Parameter
int lParam // zweiter Parameter
);
public void KillActiveXWindow()
{
// Fenster suchen
int iHandle = FindWindow( "Name der Fensterklasse" , "Name des Fensters" );
// nachricht für Fenster schliessen senden
SendMessage( iHandle, WM_SYSCOMMAND, SC_CLOSE, 0);
}
Damit sollte das Fenster dann zu sein. Wenn das nicht funktioniert, kannst du auch noch einen Mausklick auf den Button simulieren.
Original von cadi
Ich will ja nicht wissen, was die Dialogbox so von sich gibt (bitte lizensieren sie produkt x?).
"Benutzer oder Passwort falsch, bitte erneut probieren."
Original von cadi
Aber im ernst: In einer Server-Anwendung hat ein Control, welches eine DialogBox öffnet NIX zu suchen.
Das ist nicht sonderlich hilfreich. Offensichtlich hast Du noch nie mit APIs gearbeitet, die Dir der Hersteller wissend Deiner Anwendung zur Verfügung stellt, aber diesen Blödsinn nicht abschaltbar macht, bzw. eine andere Klasse hat die ohne Dialog ist aber dafür undokumentiert. Ich kann mich auch weinend in die Ecke setzen!
Original von cadi
Killen wird nicht gehen, das das Control ja im Context des Server-Prozesses läuft...
Es mag da fiese low-level-api tricks geben, aber die sollte man, wenn man nicht gerade hacker werden will für eine ernsthafte anwendung ausschliessen...
Ich lasse den Teil, der evtl. den Dialog erzeugt schon in einem extra Thread laufen. Der dümpelt dann erstmal vor sich hin ...
Original von cadi
Falls es doch nicht anders geht, solltest du über eine art watchdog nachdenken, der den OK-Click simmuliert... Aber bei dem Gedanken läuft mir ein Schauer den rücken runter!
😁 Mit einem guten alten Makrorekorder.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Original von Borg
Wie wäre es damit:Du nutzt ganz normal das Control. Wenn du dann feststellst, dass es nicht mehr reagiert (also wahrscheinlich das Dialogfenster geöffnet hat), suchst du das Fenster anhand seines Titels und sendest ihm die Nachricht für Fenster schliessen.
Alles was du dafür brauchst, ist die Fenster-Klasse und der Titel.
Dies kannst du alles mit Spy++ herausfinden.
(Wenn das ActiveX-Fenster offen ist Spy++ starten, dann im Menü Spy / Find Window..., das Zielkreuz auf die Titelleiste des ActiveX-Fensters ziehen und loslassen, bei Class steht dann die Fensterklasse, bei Caption der Name)...
Damit sollte das Fenster dann zu sein. Wenn das nicht funktioniert, kannst du auch noch einen Mausklick auf den Button simulieren.
Ja diese Idee ist durchaus machbar. Damit habe ich schon unter Win32 gute Erfahrungen. Musste da öfter Fenster und andere Anwendung prüfen (Nein keine Spyware sondern Fakerschutz, ich sags nur, weil hier offensichtlich viele Verfolgungswahn haben. Nicht böse sein aber selbst in diesem jungen Thread kommt es schon wieder zu Unterstellungen.)
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Original von tomaten
Original von cadi
Aber im ernst: In einer Server-Anwendung hat ein Control, welches eine DialogBox öffnet NIX zu suchen.Das ist nicht sonderlich hilfreich. Offensichtlich hast Du noch nie mit APIs gearbeitet, die Dir der Hersteller wissend Deiner Anwendung zur Verfügung stellt, aber diesen Blödsinn nicht abschaltbar macht, bzw. eine andere Klasse hat die ohne Dialog ist aber dafür undokumentiert. Ich kann mich auch weinend in die Ecke setzen!
Och, ich mache das schon ein paar jährchen und ich habe die wüstesten Dinge erlebt.
Nur habe ich im laufe der Jahre gelernt, das gewisse Workarounds Systeme extrem schnell instabil und sehr schwer wartbar machen.
Ich gebe ja zu, das es zu extrem kranken Situationen komen kann, wo man beginnt absolute Schweinereien zu programmieren, aber ich habe auch gelernt das es sich lohnt solche Situationen frühzeitig zu eskalieren um die Folgen zu vermeiden...
Evlt. wäre es ja möglich, das du oder dein Kunde bei dem Hersteller der API mal was Druck macht?
Manchmal hilft das (im Zweifel eher den anbieter einer api wechseln, als ein Projekt vor die Wand setzen...).
Aber so wie das bei dir klingt befürchte ich ja schlimmstes für dich...
Kunde: Hei! Die Api von XY ist toll! Günstig und macht alles was wir brauchen.
Du: ähm, die macht aber Probleme. Die API von ACME ist nicht viel teurer aber stabiler...
Kunde: Das bekommst du schon hin...
(dabei frisst der mehraufwand die DialogBox zu umgehen wahrscheinlich locker die differenz...)
XY: No one ever requested the dialog box to be not show. Hey, users want to know if the entered password is incorrect?
DU: er... mein User ist ein Server!?
XY: Your problem, this is not the intended usage of our component.
(or worse🙂 XY: Hey, in this case you need our Enterprise Version. It only costs ten times as much.
DU: aber da gibt es doch noch die undokumentierte API? wie wäre es mit einer dokumentation?
XY: Hey! this Documentation has been left blank intentionally. Sorry... But in the Enterprise Version....
(oder sind die gar der einzige Anbieter einer solchen API für was auch immer? dann hast du echt die A**schkarte...)
Original von cadi
Evlt. wäre es ja möglich, das du oder dein Kunde bei dem Hersteller der API mal was Druck macht?
Ach das wäre schön, wenn der Verantwortliche beim Kunden nicht ein Querulant wär der eigentlich den Auftrag einem "Freund" geben wollte (der jetzt aber beim API-Hersteller ist und auf unserer Seite steht) und den ganzen Schlamassel mit der API (die es nur vom Originalhersteller gibt) veranlasst hätte! Unser Produkt läuft nämlich auch ohne die. So sind unsere Grosskonzerne und ihre ITler. Projekte über Jahre verschleppen, Unmengen Knete verbraten, dann doch wieder zu uns kommen und jeden Stein in den Weg legen, den man finden kann! Und wir fragen uns, wieso es unserer Wirtschaft so beschissen geht!?
Naja, jetzt stehen wir unter Zeitdruck dieses sinnlose Konstrukt bis zur Demostellung zu implementieren. Aber den meisten hier dürfte dieses Szenario bekannt sein! Und man kann mit 1000%iger Sicherheit annehmen, dass die API dafür nicht angepasst wird. Scheiss Politik!
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Original von cadi
Könnt ihr mit C++ was anfangen?
??? Warum wieso?
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Ich habe mal (im rahmen eines anderen... noch schlimmeren) projektes einen WindowWatcher schreiben dürfen.
Der wartet auf ein bestimmtest fenster und kann dann ein kommando auführen (oder auf eine bestimmte URL im IE).
Allerdings ist halt (noch) nichts zum klicken von buttons drinnen... (das hat eineTCL-Script Sprache auufgerufen um dann mit den Fenstern was anzustellen)
aber als Basis könnte das reichen (aber bitte nicht weitergeben....)
Zur not einfach hardcoden, das wenn ein fenster gefunden wird ein WM_COMMAND an das fenster geschickt wird.
Ein andere Option wäre es, das Control in einem extra Prozess einzubetten und den Win32-MessagBox-Aufruf abzufangen.
Original von cadi
Ich habe mal (im rahmen eines anderen... noch schlimmeren) projektes einen WindowWatcher schreiben dürfen.Der wartet auf ein bestimmtest fenster und kann dann ein kommando auführen (oder auf eine bestimmte URL im IE).
Allerdings ist halt (noch) nichts zum klicken von buttons drinnen... (das hat eineTCL-Script Sprache auufgerufen um dann mit den Fenstern was anzustellen)
aber als Basis könnte das reichen (aber bitte nicht weitergeben....)
Zur not einfach hardcoden, das wenn ein fenster gefunden wird ein WM_COMMAND an das fenster geschickt wird.
🙂 Danke, aber Code dafür habe ich noch vom allerfeinsten, wie ich ja schon Borg geantwortet haben (Danke FairAd AG, R.I.P.). Den hab ich mir gestern schon aus meinen Sicherungen runtergezogen. Ich schmeisse niemals Code weg! 😁
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Original von svenson
Ein andere Option wäre es, das Control in einem extra Prozess einzubetten und den Win32-MessagBox-Aufruf abzufangen.
Das ist gemein. Nur weiss man dann nicht, was das Control daraus macht. Die Idee von Borg gefällt mir am besten. Da das aber mehrere Fenster sein können, werde ich das mit EnumWindows machen da FindWindow da zu unzuverlässig ist (findet ja nur das erste). Das Login ist nun wirklich nicht zeitkritisch 😉 da können die User auch mal 10 Sekunden warten (so als Intervall) und das Control ist sowieso nicht das schnellste. 😉
Nachtrag: Ausserdem kann ich mit einer Erweiterung dieser Suche auch andere evtl. noch auftretende dümmliche Meldungen der API killen! 😉
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Du kannst über einen Windows-Hook auch direkt auf das erstellen (oder das ändern des titels) eines fensters reagieren... damit gibt es keine Zeitverzögerung...
Original von cadi
Du kannst über einen Windows-Hook auch direkt auf das erstellen (oder das ändern des titels) eines fensters reagieren... damit gibt es keine Zeitverzögerung...
Das ist richtig, nur ob das auch in einer ASP.NET Anwendung funktioniert muss ich erst schauen. Und Hooks in .NET sind noch witziger. Habe aber schon eine Beschreibung gefunden, wie ich den Callback für EnumWindows in C# implementiere. Hooks dürften da schwerer in ASP.NET zu implementieren sein, dazu müsste ich mir wahrscheinlich wieder eine Win32 DLL bauen. 🙁 Den Intervall kann ich ja anpassen. EnumWindows belastet das System nicht wirklich. Ich werde heute Abend mal in mich gehen und beide Versionen genauer betrachten. Echtzeit ist natürlich schöner aber der Aufwand muss auch passen. Wir hatten ja früher auch Keyboard- und Mousehooks zum Schutz vor Fakern implemetiert. Muss mal wieder in den Code schauen.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Daher ja das Angebot meinen c++ win32 krams als basis zu nehmen 😉
Ist win32 nativ mit windows hook...
Das einzige was noch fehlt ist den button dann zu klicken 😉
Original von cadi
Daher ja das Angebot meinen c++ win32 krams als basis zu nehmen 😉
Ist win32 nativ mit windows hook...Das einzige was noch fehlt ist den button dann zu klicken 😉
Na das habsch doch ooch als Win32 Code! Gegen den Hook spricht, dass wir definitiv in der Produktionsumgebung keine eigene Maschine bekommen (werden eine von vielen IIS Anwendung sein). Wenn ich da in der Callback-Funktion schlampe kann ich das ganze System runterziehen, mit EnumWindows kann da nix passieren!
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Original von cadi
Ich denke dein Projekt gehört nach
> ...
Warum? Das ist ganz normal. Je größer der Laden und je spezialisierter die Admins desto schlimmer wird das. Fachabteilung will und braucht eine Software - IT fühlt sich übergangen - Lieferant muss es ausbaden. Also das ist nun wirklich nichts Besonderes.
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Ich habe ja auch nicht gesagt, dass das was besonderes sei...
Sonst würde da auch nicht täglich was neues auftauchen.
Aber es passt halt in die Kategorie "holy wtf!?"
Und ein Web-Server, der eine Falsches-Passwort-Meldung wegklickt ist schon ein WTF!
Original von cadi
Und ein Web-Server, der eine Falsches-Passwort-Meldung wegklickt ist schon ein WTF!
Naja, bevor der nicht dem verantwortlichen Admin jedes mal den dicken Finger zeigt bin ich nicht zufrieden! 😉 Das dann nach der Probestellung. 😁
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.