Weiterentwicklung Chromium Browser Komponente

[Warf]

Wie ist der Stand bei fpCEF3 nach einem Jahr ohne Posts in dem Thread ?

Kann man damit auch Flash im Browserfenster steuern ? Hintergrund ist, das ich ein Browserfenster mit Flashinhalt steuern will - Mausbewegungen, Erkennung von Objekten und Tatasturkommendos senden. Ich möchte etwas an Routineaufgaben automatisieren
Nur bevor ich da weiter darüber sinne, will ich mal die prinzipielle Machbarkeit hinterfragen. Wenn ja, dann mache ich sowieso einen neuen Thread bei Bedarf auf.

Andreas

Für Flash benötigst du keinen Browser, Flash ist eigene Software von Drittanbietern (Adobe).

Sieh dir am besten mal die Flash ActiveX Komponente an

[BeniBela]

Kann man damit auch Flash im Browserfenster steuern ? Hintergrund ist, das ich ein Browserfenster mit Flashinhalt steuern will - Mausbewegungen, Erkennung von Objekten und Tatasturkommendos senden. Ich möchte etwas an Routineaufgaben automatisieren

Ich wollte auch sowas machen und habe am Ende das Flashprogramm decompiliert, den Flashcode geändert, und das ganze dann wieder kompiliiert

[Christian]

Dann eben nochmal

Wie ist der Stand bei fpCEF3 nach einem Jahr ohne Posts in dem Thread ?

[Michl]

Ich entwickle zwar nicht an fpCEF3, aber mit den CEF3 Framework 1750 läuft der Browser seit seiner Zeit bei mir unter Windows 7, Lazarus 1.5 Trunk, FPC Trunk sehr stabil und bin auch sehr zufrieden damit (war auch kurz beim Lazarustreffen bei meiner Projektvorstellung ersichtlich).

Zum Thema hatte ich auch eine Wiki-Seite verfasst http://wiki.lazarus.freepascal.org/fpCEF3/de.

Unter Lazarus lief bei mir auch WACEF mit CEF3 Framework 1916, als ich vor einiger Zeit aktuellere Binaries testen wollte, gingen diese nicht mehr (hatte dort dazu auch nachgefragt, bis dato keiner Rückmeldung: https://bitbucket.org/WaspAce/wacef). Aktueller Stand des Frameworks ist 2478 - habe ich aber noch nicht wieder getestet.

[downloaditweb]

Hallo,
die aktuelle Version von fpCEF sollte stabil unter Windows und Linux laufen, das benutzte CEF-Framework ist leider nicht auf dem neuesten Stand.

Ich habe zwar schon seit längerem eine aktualisierte Version für Windows, die neueren CEF3-Versionen haben aber (nach meiner Einschätzung) ein grundlegende Problem unter Linux, siehe https://github.com/dliw/fpCEF3/issues/13
Für die neuesten CEF-Versionen habe ich das noch nicht überprüft.

Für Windows gibt es auch WACEF und mein Fokus liegt definitiv auf Linux, somit wird es erst eine neue Version erst geben, wenn ich das Problem lösen kann.

Es gibt einen externen Beitrag, der ein erster Schritt für die Unterstützung von Mac OSX ist, ich bin aber noch nicht dazugekommen, das zu integrieren.

[downloaditweb]

So schnell kann's gehen - fpCEF ist jetzt wieder auf der Höhe der Zeit

[Michl]

Das ist mal eine Nachricht, die mich wirklich freut!!!

Leider funktioniert ein erster Test bei mir nicht:

Code: Alles auswählen

(gdb) run
Starting program: C:\04 Simple FPCEF/project1.exe 
[New Thread 228.0x1184]
[New Thread 228.0x134c]
 
Program received signal SIGTRAP, Trace/breakpoint trap.
0x516a530a in libcef!cef_time_to_timet () from C:\04 Simple FPCEF\libcef.dll
(gdb) bt
#0  0x516a530a in libcef!cef_time_to_timet ()
   from C:\04 Simple FPCEF\libcef.dll
#1  0x51670e06 in libcef!cef_time_to_timet ()
   from C:\04 Simple FPCEF\libcef.dll
#2  0x5377bf7f in libcef!TerminateProcessWithoutDump ()
   from C:\04 Simple FPCEF\libcef.dll
#3  0x00000003 in ?? ()
#4  0x00000000 in ?? ()

Weißt du, woran das liegen könnte?!

Windows 7 64bit, Lazarus 1.5 r50105M FPC 3.1.1 r32092 i386-win32-win32/win64
cef_binary_3.2454.1342.g4e94f47_windows32

Habe noch nicht 64bit und/oder andere cef_binarys getestet - werde ich später nachholen, aber evtl. hast da da gleich einen Hinweis für mich?!

[Edit] noch mit Debug cef_binaries:

Code: Alles auswählen

(gdb) run
Starting program: C:\04 Simple FPCEF/project1.exe 
[New Thread 5108.0xd04]
[New Thread 5108.0x114c]
 
Program received signal SIGTRAP, Trace/breakpoint trap.
0x10747707 in libcef!cef_time_to_timet () from C:\04 Simple FPCEF\libcef.dll
(gdb) bt
#0  0x10747707 in libcef!cef_time_to_timet ()
   from C:\04 Simple FPCEF\libcef.dll
#1  0x106620fe in libcef!cef_time_to_timet ()
   from C:\04 Simple FPCEF\libcef.dll
#2  0x173a6f8e in libcef!TerminateProcessWithoutDump ()
   from C:\04 Simple FPCEF\libcef.dll
#3  0x156ee03a in libcef!TerminateProcessWithoutDump ()
   from C:\04 Simple FPCEF\libcef.dll
#4  0x1034a2ff in libcef!cef_string_list_value ()
   from C:\04 Simple FPCEF\libcef.dll
#5  0x10349587 in libcef!cef_string_list_value ()
   from C:\04 Simple FPCEF\libcef.dll
#6  0x1025b188 in libcef!cef_initialize () from C:\04 Simple FPCEF\libcef.dll
#7  0x005498e3 in CEF3LIB_$$_CEFINITIALIZE$$BOOLEAN ()
#8  0x00549973 in CEF3LIB_$$_CEFBROWSERHOSTCREATEBROWSERSYNC$crc7F59A86A ()
#9  0x005455b2 in CEF3LCL$_$TCUSTOMCHROMIUM_$__$$_CREATEBROWSER ()
#10 0x0054564f in CEF3LCL$_$TCUSTOMCHROMIUM_$__$$_CREATEWND ()
#11 0x004f0431 in TWINCONTROL__CREATEHANDLE (this=<error reading variable>)
    at ./include/wincontrol.inc:7340
#12 0x004f1591 in TWINCONTROL__HANDLENEEDED (this=<error reading variable>)
    at ./include/wincontrol.inc:7786
#13 0x004f0c60 in TWINCONTROL__CREATEWND (this=<error reading variable>)
    at ./include/wincontrol.inc:7475
#14 0x00416db1 in TSCROLLINGWINCONTROL__CREATEWND (
    this=<error reading variable>) at ./include/scrollingwincontrol.inc:23
#15 0x0041c8a7 in TCUSTOMFORM__CREATEWND (this=<error reading variable>)
    at ./include/customform.inc:2594
#16 0x0041d6c8 in TFORM__CREATEWND (this=<error reading variable>)
    at ./include/customform.inc:3060
#17 0x004f0431 in TWINCONTROL__CREATEHANDLE (this=<error reading variable>)
    at ./include/wincontrol.inc:7340
#18 0x004f1591 in TWINCONTROL__HANDLENEEDED (this=<error reading variable>)
    at ./include/wincontrol.inc:7786
#19 0x00423414 in TAPPLICATION__CREATEFORM (INSTANCECLASS=<incomplete type>, 
    REFERENCE=void, this=<error reading variable>)
    at ./include/application.inc:2178
#20 0x00402c86 in main () at project1.lpr:18
(gdb) 

[downloaditweb]

Habe es gerade nochmal getestet und kann das nicht nachvollziehen. Passiert das auch mit dem Beispielprojekt LCLSimple?
Versuch mal bitte die exe ohne Debugger direkt zu starten, also nicht aus Lazarus heraus. SIGTRAP kann eigentlich nur beim Debuggen auftreten.

Edit:
Die Version 3.2454.1342 ist korrekt, es hat sich zwischen 3.2454.1333 und dieser Version die API geändert. Ich seh schon, das Versions-Wirrwarr geht erst los

[Michl]

Passiert das auch mit dem Beispielprojekt LCLSimple?

Ja, das gleiche Problem. (PS: Könntest du in den Projekteinstellungen das Ziel etc. "gemäß Voreinstellungen" definieren, sonst kommt immer die Meldung "Can't find unit System". Ich weiss, wo man da suchen muss, andere Nutzer evtl. nicht)

Versuch mal bitte die exe ohne Debugger direkt zu starten, also nicht aus Lazarus heraus. SIGTRAP kann eigentlich nur beim Debuggen auftreten.

Ich habe zuerst versucht aus Lazarus heraus die Exe zu starten, dann von der Kommandozeile aus, mit/ohne Debugsymbolen in den Binaries auch ohne Debugsymbolen in der Exe, immer mit dem gleichen Ergebnis (ohne Debugsymbolen gibt es halt einen Unknown Runtime Error 255).

Getestet habe ich die 32bit Lazarusversionen 1.5 und 1.4.4 unter Windows 7 64bit.

Werde heute Abend noch 64bit Lazarus und andere Binaries testen - mal sehen.

[downloaditweb]

Projekteinstellungen:
Es gibt entsprechende Erstellmodi: http://wiki.freepascal.org/IDE_Window:_ ... .C3.A4hlen
Damit kann ich mit Start > Mehrere Modi zum Testen alles auf einmal erstellen. Bei "Voreinstellung" müsste ich das jeweils mühsam umstellen.
Oder meinst du etwas anderes?

Habe für alle Beispielprojekte jeweils die 32bit- und 64bit-Versionen vor Release auch auf Win7, 64bit getestet. Die .exes aber unter Linux compiliert.
In Wine ist die 32bit-Version bei manchen Seiten abgestürzt (bei google.com, nicht aber bei example.com), das hat aber wahrscheinlich mit Wine zu tun - unter Windows lief alles problemlos.

Ich habe mal "meine" exes angehängt, wenn es an fpCEF oder CEF liegt, müsste damit das gleiche Problem auftauchen. Falls nicht könnte das auch mit Änderungen in FPC 3.1.1 zusammenhängen (Strings), ich habe nur mit 2.6.4 getestet.

[Michl]

Es gibt entsprechende Erstellmodi: http://wiki.freepascal.org/IDE_Window:_ ... .C3.A4hlen
Damit kann ich mit Start > Mehrere Modi zum Testen alles auf einmal erstellen. Bei "Voreinstellung" müsste ich das jeweils mühsam umstellen.
Oder meinst du etwas anderes?

Ja genau. War aber nur ein Hinweis, wenn es dir hilft, dann lass es so (ich finde es auch so toll, dass du deine Arbeit teilst).

Nachdem ich nach einigem Rumprobieren deine Exe zum Laufen bekommen habe und ein wenig mit meinem Projekt herumexperimentiert habe, weiss ich jetzt wo der Fehler lag. Mit 1750 war es möglich den Pfad á la:

Code: Alles auswählen

procedure TForm1.FormCreate(Sender: TObject);
begin
  CefResourcesDirPath := 'Resources';
...

festzulegen. Das ist scheinbar jetzt nicht mehr möglich. Kommentiere ich diese Zeile aus und kopiere den Verzeichnisinhalt in das Projektverzeichnis, kann ich mein kleines Beispielprojekt ebenfalls starten.

Werde noch ein wenig testen und später die Wikiseite entsprechend aktualisieren.

Vielen Dank für deine Mühe bisher!!!

[downloaditweb]

Ok, ich kann den Crash jetzt nachvollziehen. Da hat sich tatsächlich etwas gegenüber der alten Version verändert.

Unabhängig davon sollten alle Pfade in CEF immer absolut angegeben werden! Beim CefBrowserSubprocessPath funktioniert es ausnahmsweise auch mit einem relativen Pfad und vorangestelltem ./

Die "Lösung" sieht also wie folgt aus:

Code: Alles auswählen

 
Var
  Path: ustring;
begin
  Path := GetCurrentDirUTF8 + PathDelim;
  CefResourcesDirPath := Path + 'Resources';
  CefLocalesDirPath := Path + 'Resources' + PathDelim + 'locales';
  ...
 

Hab das aber noch nicht unter Win getestet.

Wichtig ist, dass die icudtl.dat mit der exe im gleichen Verzeichnis liegen muss.

Ein Hinweis fürs Wiki:
Der Aufruf von CefInitDefault an dieser Stelle ist überflüssig (in der neuen Version auch deprecated). Die Einstellungen müssen so oder so spätestens im Form.Create der Form gesetzt werden, in dem sich der Browser befindet.

Ein expliziter Aufruf von CefInitialize ist dann sinnvoll, wenn man keinen SubProcess verwendet und die erste Form, die angezeigt wird, nicht die Form mit dem Browser ist - CEF muss dann früher initialisiert werden. Das macht man aber am besten gleich am Anfang des Programms (.lpr) oder spätestens im Initialization-Abschnitt der Unit mit Browser.

Ansonsten ist der Wiki-Eintrag echt hilfreich - danke.

[Michl]

Unabhängig davon sollten alle Pfade in CEF immer absolut angegeben werden!

Danke für die Info.

Die "Lösung" sieht also wie folgt aus:

Ich habe das mit "PrjPath := UTF8Decode(ExtractFilePath(ParamStr(0)));" gelöst, da der Compiler sonst Warnungen unter Laz.1.5 produziert.

Mit dieser Änderung halte ich es generell bei einem Minimalbeispiel für einfacher, wenn man den Inhalt des Verzeichnisses "Resources", gleich dem Verzeichnis "Release", einfach in das Projektverzeichnis kopiert. Habe das Wiki entsprechend aktualisiert.

Ein expliziter Aufruf von CefInitialize ist dann sinnvoll, wenn man keinen SubProcess verwendet und die erste Form, die angezeigt wird, nicht die Form mit dem Browser ist - CEF muss dann früher initialisiert werden. Das macht man aber am besten gleich am Anfang des Programms (.lpr) oder spätestens im Initialization-Abschnitt der Unit mit Browser.

Stimmt, das benötige ich in einem Projekt, da ich dort das TChromium nicht auf dem Hauptformular, sondern auf einem untergeordneten Formular liegen habe.

Ansonsten ist der Wiki-Eintrag echt hilfreich - danke.

Danke für die Blumen

Das Wiki sollte jetzt wieder passen. Habe das dort beschriebene Vorgehen mit Windows 7 unter Lazarus 1.5 mit FPC 3.1.1 32bit und 64bit und Lazarus 1.4.4 mit FPC 2.6.4 32bit und 64bit getestet. Es läuft jeweils ohne Fehler/Warnungen/Hinweise durch. Es wäre gut, wenn jemand das Minimalbeispiel für Linux testen/anpassen könnte. Da fehlt mir leider jeg­li­ches Wissen.

[downloaditweb]

Eine neue Version von fpCEF für CEF 3.2526 steht jetzt bereit.

Edit:
Linux-Minimalbeispiel:
Wenn das unter Windows funktioniert, gibt es keinen Grund, wieso es das unter Linux nicht tun sollte.

Die einzige kritische Stelle ist

Code: Alles auswählen

ParamStr(0)

, unter Linux liefert das nicht in allen Fällen (z.B. bei Links im Pfad) den Pfad zur ausgeführten Datei.

MMn ist die einfachste Option gar keine Pfade zu setzen (Minimalbeispiel) und folgende Dateistruktur einzuhalten:

Code: Alles auswählen

 
├── cef_100_percent.pak
├── cef_200_percent.pak
├── cef_extensions.pak
├── cef.pak
├── devtools_resources.pak
├── icudtl.dat
├── libcef.so / libcef.dll
├── locales
│   ├── am.pak
│   ├── ...
│   └── zh-TW.pak
├── natives_blob.bin
├── snapshot_blob.bin
├── simple(.exe)
└── subprocess(.exe)
 

[Michl]

Super, danke für die Info, werde ich demnächst testen!

Die einzige kritische Stelle ist

Code: Alles auswählen

ParamStr(0)

, unter Linux liefert das nicht in allen Fällen (z.B. bei Links im Pfad) den Pfad zur ausgeführten Datei.

Danke für den Hinweis, werde ich abändern.