TWebbrowser + Application.ProcessMessages = Probleme?

[MartinKumeran]

Hallo,

sind irgendjemandem schon einmal Freeze-Probleme bei der Benutzung des TWebBrowsers sowie des Befehls Application.ProcessMessages untergekommen?
Konkret möchte ich innerhalb einer Prozedur darauf warten dass der TWebBrowser eine Website fertig geladen hat und benutze dafür folgende Wartefunktion:

Delphi-Quellcode:

procedure Wait(Secs: Cardinal);
var
  ActualTime, LastTime, WaitingTime: Cardinal;
begin
  if Secs = 0 then exit;
  WaitingTime := Secs*1000;
  LastTime := GetTickCount;

  While true do begin //Endlosschleife welche durch break beendet wird
    Application.ProcessMessages;
    sleep(1);
    ActualTime := GetTickCount;
    if LastTime > ActualTime then begin //GetTickCount wurde von Windows zurueckgesetzt
      LastTime := ActualTime;
      Continue;
    end;
    if ActualTime - LastTime >= WaitingTime then break;;
  end;
end;

Mein Programm prueft ob das Ready-Ereignis des TWebBrowsers ausgelöst worden ist und ruft ansonsten die obenstehende Funktion mit jeweils einer Sekunde Wartezeit auf.
Diese Kombination aus dem laufenden Laden einer URL innerhalb des WebBrowsers und dem Aufruf von Application.ProcessMessages führt jedoch manchmal zu einem kompletten Freeze der Anwendung. In einem solchen Fall läuft die Anwendung einwandfrei bis zum Erreichen des ProcessMessages-Befehl um diesen nie wieder zu verlassen.
Hat jemand schon einmal etwas ähnliches beobachtet oder gar eine Lösung gefunden?
Im Internet finden sich verschiedentliche Spuren ähnlicher Probleme, beispielsweise hier:

Zitat:

One last point: Be careful with the use of Application.ProcessMessages when you use WebBrowser. I've avoided it except where fetches are added, which waits if the resultProcessor is busy. I don't know if it's the way events are sent, but I found that setting a label and calling application.ProcessMessages could force the same event to happen again. This occurred more in the debugger, but if you get odd behavior, comment them out.

Gibt es eine Möglichkeit das was innerhalb von Application.ProcessMessages passiert zu debuggen? Oder noch besser: Gibt es einen alternativen Befehl in Delphi zu ProcessMessages welcher trotzdem dafür sorgt dass der TWebBrowser weiter arbeiten kann?

Viele Grüße und Danke im Voraus,

Martin Kumeran

[jaenicke]

Es ist auch keine gute Idee darauf zu warten. Windows ist ereignisorientiert und deshalb sollte man auch einfach die entsprechenden Ereignisse benutzen, dann stellt sich das Problem gar nicht erst... :roll:

Zum Beispiel:
http://www.cryer.co.uk/brian/delphi/...cumentComplete

[MartinKumeran]

Zitat:

Zitat von jaenicke

Es ist auch keine gute Idee darauf zu warten. Windows ist ereignisorientiert und deshalb sollte man auch einfach die entsprechenden Ereignisse benutzen, dann stellt sich das Problem gar nicht erst... :roll:

Zum Beispiel:
http://www.cryer.co.uk/brian/delphi/...cumentComplete

Du hast natürlich recht dass es die beste Methode wäre nach dem Befehl zum Laden der URL die aufrufende Funktion zu verlassen und ohne Benutzung einer Wartefunktion auf die WebBrowser-Ereignisse zu warten. Unglücklicherweise sind die Notwendigkeiten zum Warten auf eine WebSite in meinem Code aber innerhalb von komplexen Verschachtelungen und Schleifen so dass ein zwischenzeitliches Verlassen der Funktion nicht praktikabel ist. Es sei denn natürlich es gäbe eine Möglichkeit in Delphi nach einem Verlassen einer Funktion später wieder genau an diesen Punkt zu springen, inklusive aller vorangegangenen Werte für Schleifen und Bedingungen.

[jaenicke]

Dann ist dein Konzept schlecht durchdacht...

Du könntest es einmal ohne Sleep versuchen, vielleicht liegen die Probleme auch da begründet, denn während der Zeit ist das Programm schließlich stillgelegt...
Stattdessen gibt es Delay, dabei brauchst du nicht einmal selbst Application.ProcessMessages einzusetzen:
http://www.delphipraxis.net/internal...ect.php?t=7355

[mkinzler]

Warum eigentlich warten. reagiere doch auf die Fertigmeldung (.onDocumentComplete())

[jaenicke]

Habe ich ja geschrieben, aber er hat offenbar ein so schlechtes Konzept, dass er das da schlecht einbauen kann...

[mkinzler]

Scheinbar mögen die meisten keine "guten" Lösungen sondern sind Stolz es möglich dreckig lösen zu können. in der zeit in dem man diesen "Mist" ausbaldovert könnte man es auch gut richtig machen und alles würde funktionieren. Dirty code hingegn erzeugt meist Nebeneffekte und deshalb Folgefehler.

[MartinKumeran]

Ich weiß nicht ob man mir unbedingt ein schlechtes Konzept unterstellen kann, ab einem bestimmten Komplexitätsgrad wird einfach ein vollkommen unübersichtlicher QuellCode geschaffen wenn man ständig aus einer Funktion hüpfen muss um sie nach Eintreten eines Ereignisses durch einen erneuten Aufruf wieder fortzusetzen, gerade wenn man mit Schleifen und Verzweigungen arbeitet.

Ich habe meine Funktion mit der von jaenicke vorgeschlagenen ersetzt um das Sleep zu vermeiden, leider tritt der selbe Effekt weiterhin auf wenn der Befehl Application.ProcessMessages ausgeführt wird.

Um zu prüfen was das Programm genau macht habe ich mir ein Log der Message-Abarbeitung der Anwendung ausgeben lassen, der von mir sogenannte Freeze ist streng genommen keiner, ankommende Messages werden weiter verarbeitet - allerdings mit einer ewigen Unterbrechnung von teilweise mehreren Minuten indem anscheinend die TWebBrowser-Komponente intern (?) irgendetwas macht. Die reine Abarbeitung des MessageQueues funktioniert gut. Application.ProcessMessages ist eben doch mehr als ein reiner Befehl zum Abarbeiten der anstehenden Messages. Nach einer Ewigkeit wird der ProcessMessages-Befehl dann tatsächlich auch beendet, das Ganze kann aber durchaus 10 Minuten und mehr dauern...

[jaenicke]

Zitat:

Zitat von MartinKumeran

ab einem bestimmten Komplexitätsgrad wird einfach ein vollkommen unübersichtlicher QuellCode geschaffen wenn man ständig aus einer Funktion hüpfen muss um sie nach Eintreten eines Ereignisses durch einen erneuten Aufruf wieder fortzusetzen, gerade wenn man mit Schleifen und Verzweigungen arbeitet.

Das ist ja genau das Problem.

Ich unterteile die verschiedenen Aufgaben in einzelne Module. Und wenn ich zum Beispiel mit Indy Daten aus dem Internet herunterlade, dann kapsele ich das ggf. in Klassen. Diese wiederum reagieren auf die diversen Events und leiten diese ggf. wiederum via Event weiter. TWebBrowser benutze ich dafür allerdings nicht, da ich keine visuelle Darstellung brauche und TWebBrowser dann ja außer für JavaScript oder so Schwachsinn wäre.

Ich weiß, dass es eine Umstellung ist voll ereignisorientiert zu denken und zu entwickeln, aber insbesondere bei komplexeren Aufgaben führt daran kaum ein Weg vorbei...

Muss es denn TWebBrowser sein? Welche Funktionen brauchst du denn genau? Reine visuelle Darstellung von Webseiten bieten auch andere Komponenten teilweise.