Laden...

Click-Event beim WebBrowser, egal wo genau geklickt wird

Erstellt von Palladin007 vor 12 Jahren Letzter Beitrag vor 12 Jahren 1.415 Views
Palladin007 Themenstarter:in
2.079 Beiträge seit 2012
vor 12 Jahren
Click-Event beim WebBrowser, egal wo genau geklickt wird

Moin

Ich suche einen Event, der ausgeführt wird, sobald ich irgendwo auf dem Webbrowser etwas anklicke. Egal, ob es eine Wirkung hat, oder nicht. Es geht nur darum, ihn an zuklicken.

Aber wenn ich die Evenets so durch schaue, finde ich nichts.

Wie kann ich das trotzdem bekommen?

Gruß

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo Palladin007,

ich würde an deiner Stelle mal schauen, ob du in der WndProc nicht irgendeine Nachricht bekommst, aus der du erkennen kannst, dass geklickt wurde.

herbivore

3.170 Beiträge seit 2006
vor 12 Jahren

Hallo,

wenn Du die angezeigt Seite auch selbst geschrieben hast, köntest Du per Javascript im document.onmousedown über window.external eine Methode in Deiner Anwendung aufrufen, schau Dir dazu mal Webbrowser.ObjectForScripting an.

Anderfalls hast Du ggf. auch die Möglichkeit, ein eigenes Script-Tag ins Dokument einzubauen, das genauso vorgeht. Beachte aber, dass Du dann besser prüfst, ob document.onmousedown schon einen Handler hat, und wenn ja, diesen zu puffern und vor oder nach der externen Methode aufzurufen.

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

Palladin007 Themenstarter:in
2.079 Beiträge seit 2012
vor 12 Jahren

Ne, hab ich nicht selber geschrieben.

Das mit der Nachricht, die ich überprüfen kann, werd ich als erstes versuchen, weil ich von Scripting keine Ahnung habe. Noch nicht ^^

Aber ich habe noch eine Idee:

Könnte man nicht den Maus-Klick-Event allgemein verwenden und dann den Ort der Maus berprüfen? Wenn die Maus sich nun über dem Webbrowser befindet, wird ausgeführt, was ausgeführt werden soll und wenn nicht, einfach nix, oder etwas anderes.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo Palladin007,

für die meisten Controls könnte man das Click-Ereignis verwenden, aber gerade für WebBrowser.Click (bzw. genauer WebBrowserBase.Click) gilt laut MSDN nunmal:

Dieses Ereignis wird von diesem Steuerelement nicht unterstützt.

Deshalb ja auch mein Vorschlag auf die WndProc auszuweichen.

herbivore

Palladin007 Themenstarter:in
2.079 Beiträge seit 2012
vor 12 Jahren

Also irgendwie verstehe ich nicht, wie du das meinst.

Muss ich da diese Methode verwenden:

            Message msg = new Message();
            base.WndProc(ref msg);

Die gibt mir dann eine Nachricht, mit der ich nichts anfangen kann.
Auch, wenn ich die Nachricht durch ein Click-Event auf einen Button ausgeben lasse.

Außerdem, wie soll ich mir diese Nachricht übergeben lassen?
Schließlich gibt es kein Click-Event beim WebBrowser.

Gruß

Edit:

Hab durch Zufall einen Hinweis auf diese Methode gefunden:

System.Threading.ThreadPool.QueueUserWorkItem(WaitCallback)

Das funktioniert auch ganz toll, nur bringt mir das nichts, weil das nicht zulässt, dass ich andere Elemente in der Form verändere.
Aber genau das soll ja passieren.

Kann ich das Problem irgendwie umgehen, oder bin ich da auf dem Holzweg?

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo Palladin007,

du musst die WndProc natürlich überschreiben, nicht aufrufen. (Hast du überhaupt mal danach gesucht gehabt?

Was dir QueueUserWorkItem in dem Zusammenhang bringen soll, weiß ich nicht. Aber die Antwort, wie man aus dem WaitCallback aufs GUI zugreifen kann, steht in [FAQ] Controls von Thread aktualisieren lassen (Control.Invoke/Dispatcher.Invoke). Auch das hättest du leicht von alleine finden können.

Bitte beachte daher [Hinweis] Wie poste ich richtig? Punkt 1.1.1.

herbivore

Palladin007 Themenstarter:in
2.079 Beiträge seit 2012
vor 12 Jahren

QueueUserWorkItem soll, so habe ich es verstanden, parallel zum eigentlichen Programm eine Methode ausführen.
Diese Methode habe ich dann in meiner Form-Klasse und die wartet mittels einer while-Schleife solange, bis irgendwo geklickt wird. Wenn dann geklickt wird, überprüft sie noch, ob zu diesem Zeitpunkt die Maus sich über dem Webbrowser befindet.
Wenn dem so ist, wird das ausgeführt, was ausgeführt werden soll, wenn nicht, wartet er weiter.

Hat auch wunderbar funktioniert, lässt aber keine Änderungen an der Fomr-Klasse zu, obwohl die Methode sich darin befindet.

Werd mir nachher mal deinen Text dazu durchlesen.

Was WndProc angeht, weiß ich ehrlich gesagt immer och nicht, wie du das meinst.
Ich werd jetzt gleich mal etwas damit rum experimentieren, vielleicht find ich es ja raus^^

Gruß

Edit:
Ich weiß jetzt, was du meinst.
Aber wie soll ich aus den ganzen Nachrichten heraus filtern, welche nun zum WebBrowser gehört?
Hab mir mal alle in einer Text-Box anzeigen lassen und wenn ich dann beim Ausführen immer irgendwo hin klicke, oder eine Seite lade und dort navigiere, sehe ich, was bei den Nachrichten passiert.
Aber endweder die werden zu schnell aktualisiert, oder es gibt keine Nachricht, wenn ich irgendwo klicke.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo Palladin007,

im GUI darf man nicht warten. Siehe [FAQ] Warum blockiert mein GUI?

Ich finde es ehrlich gesagt etwas zäh und nicht im Sinne des Forums, wenn wir nicht weiterkommen, wenn du immer wieder an so grundlegenden Punkten hängst. Natürlich haben wir alle klein angefangen, andererseits erwarten wir eben zu recht, dass vor der Eröffnung eines Threads die Grundlagen (hier also die der Windows Forms Programmierung) bekannt sind.

herbivore