Delphi 12: TEdgeBrowser PrintAsync

[looseleaf]

Liebe Gemeinde!

Wir haben Delphi 12 gerade installiert und versuchen, den TEdgeBrowser dazu zu bringen, eine HTML Datei auszudrucken. mit e.ExecuteScript('window.print()'); geht das zwar, aber nicht ohne den Druckdialog. Und wenn das WebView gar nicht angezeigt wird, sondern wir nur ganz ohne UI eine HTML-datei drucken wollen, dann überhaupt nicht.
Es gäbe dafür lt. Microsoft-Doku PrintAsync als Methode, doch die ist in Winapi.WebView2 nicht ausgeführt.

Übersehe ich was oder hat jemand eine Idee, wie wir ihm das beibringen können?

Danke
Stefan

[himitsu]

Schau mal ins GetIt, da gibt es seit Kurzem etwas, wo nahezu die komplette WinAPI automatisiert übersetzt wurde.
"Windows API from WinMD"
Ich hätte es hier verlinkt, aber es wird im https://getitnow.embarcadero.com nicht gelistet. :shock:

Microsoft stellt dafür seit 'ner Weile passende Daten bereit. (gut, schon seit 3 Jahren und jetzt hatte Emba es endlich bemerkt/geschafft)
https://learn.microsoft.com/de-de/uw...ef/winmd-files
https://github.com/microsoft/win32metadata


Alternativ mal versuchen das Fenster dennoch anzuzeigen? (Wenn ich nicht sichtbar bin, würde ich auch faul sein und mich nicht malen wollen :stupid:)
Außerhalb des Desktops, mit ShowWindows+SW_SHOWNOACTIVATE, anstatt Visible:=True oder Show. (aber vielleicht bemerkt es dann dennoch, dass es eigentlich nicht sichtbar ist)

[Bernhard Geyer]

Edge dürfte vermutlich nicht ohne gültigen Windows-Handle funktionieren.
Trick ist hier:
- Edge-Control auf ein nicht sichtbares Form legen
- Mit HandleNeeded dafür sorgen das alle Controls ein gültiges Handel haben (ohne angezeigt zu werden).

[looseleaf]

Danke euch für die Rückmeldungen. Am schönsten fände ich es, wenn einfach die Interfaces da wären :/

Ich glaube, ich gehe zurück und mache eine Internet Exlorer Engine aus dem TWebBrowser, und verwende das bisherige Drucken...

[Phoenix]

Zitat:

Zitat von looseleaf (Beitrag 1530995)

Ich glaube, ich gehe zurück und mache eine Internet Exlorer Engine aus dem TWebBrowser, und verwende das bisherige Drucken...

Das ist eher eine schlechte Idee. Das macht Dir das Leben in absehbarer Zeit nur noch schwieriger, insbesondere was das Layouting der Print-Sachen angeht.
Ich bin inzwischen dazu übergegangen, Printing nicht mehr in-App zu machen.

Gut, ich baue auch schon länger eher API-Backends und das UI ist im Prinzip seit 10+ Jahren immer schon eine Webanwendung, aber drucken mache ich über HTML -> Datei, Konsolenanwendung die HTML-Datei -> PDF baut und dann wird dem User entweder das PDF präsentiert oder ich sende das direkt an den Drucker.

Ja, man muss kurz auf einen externen Prozess warten, aber dafür kann ich das Ding in so ziemlich jeder Konstellation immer wieder zuverlässig verwenden.

[Der schöne Günther]

Zitat:

Zitat von Phoenix (Beitrag 1530996)

Konsolenanwendung die HTML-Datei -> PDF baut

Das ist ja der eigentlich interessante Schritt. Kannst du mehr dazu erzählen, wie genau, welche Technik du einsetzt?

[Phoenix]

Zitat:

Zitat von Der schöne Günther (Beitrag 1530997)

Das ist ja der eigentlich interessante Schritt. Kannst du mehr dazu erzählen, wie genau, welche Technik du einsetzt?

Klar, gerne :thumb:

Ich habe da ein paar mögliche Tools:

Erstens: Einfach Chrome verwenden.

Code:

chrome --headless --print-to-pdf="c:\\{{path and file name}}.pdf" https://google.com

Du kannst hinten auch nen lokalen Pfad angeben. Nachteil: Formatting / Layouting ist ein wenig schwierig, insbesondere wenn es um Seitenumbrüche geht.
Was Du damit auch nicht sinnvoll hinbekommst sind Wechsel zwischen Hoch- und Querformatiken Seiten in einem Dokument.

Zum zweiten die kommerzielle und ehrlich gesagt am schmerzfreiesten Variante: PrinceXML.
Ja, Kommerziell. Ja, nicht ganz billig. Aber die Prince-Leute haben die Themen bedacht und bieten an mit speziellen CSS-Rules ein einigermassen sinnvolles Layouting hin zu bekommen. Nachteil hier: Die JS-Engine ist nicht komplett. Chart.js geht z.B., aber komplexere JS-Dinge wie komplette Angular-SPAs kannst Du in Prince leider nicht rendern.

Diese zwei Varianten funktionieren problemlos und auf Windows, Linux und Mac. Sie brauchen nur entweder Chrome oder das jeweilige Plattform-Spezifische Prince-Executable und that's it.

Kommen wir zu den etwas aufwändigeren aber auch mächtigeren Methoden:

Wenn Du node.js auf dem System hast oder haben kannst:
Puppeteer oder PhantomJS.

Puppeteer erlaubt es, einen Chrome zu steuern. PhantomJS ist eine andere Möglichkeit, einen Browser Headless (also ohne UI) fernzusteuern.
Beides wird gerne zum automatisierten Testen von Webseiten verwendet. Du hast in beiden Varianten einen kompletten Browser im Hintergrund.
Hiermit kannst Du z.B. Seiten einer SPA rendern, Eingaben simulieren, eine Berechnung in JS ausführen lassen und dann das Ergebnis drucken. Das ganze geht in ein Paar (meist < 100) Zeilen Javascript.

Am Ende rufst Du auch hier nur node.js DeinScript.js auf und übergibst ggf. Parameter für die Eingabe-Datei und die Ausgabe-Datei.
Die beiden Libraries abstrahieren den Browser so weit weg das man zu 99% keine breaking changes hat wenn man den Browser und damit die Libs aktualisiert.


Alles was darüber hinaus geht ist dann deutlich aufwändiger.
Hier habe ich mit CEF (Chromium Embedded Framework) gearbeitet, konkret CefSharp, um den Browser aus meinen .NET Anwendungen heraus zu steuern.
CEF selber ist aber C/C++ und kann aus nativen Anwendungen auch direkt heraus als DLL aufgerufen werden.

Aber da man hier direkt gegen die Chrome-API geht und das nicht von einem weg abstrahiert wird muss man bei einem Update schonmal mit breaking Changes rechnen und man muss wirklich jeden Call selber machen. Das ist dann in der eine Ebene tiefer als TEdgeBrowser, aber eben mit dem Vorteil das Du wirklich die komplette API zur Verfügung hast. Edge ist ja auch nur ein Chromium mit anderem UI drumrum.