Probleme mit Interfaces beim Nutzen von Edge/WebView als Ersatz für TWebBrowser

[BobTheBuilder]

Hallo zusammen,

(Ich benutze Delphi 10.3, aber das kann man irgendwie nicht auswählen)

ich habe gemerkt, dass ich mich mit Interfaces überhaupt nicht auskenne und auf dem Schlauch stehe, um eine theoretisch sehr einfache Erweiterung an einem Beispiel vorzunehmen.

Beispiel kommt aus der Antwort von hier:
https://stackoverflow.com/questions/...lphi-c-builder

Einfach den Code in eine Form kopieren (und vielleicht den Form-Namen berichtigen) und schon hat man Edge als Steuerelement in einer Form laufen.

Ich benötige jetzt die Möglichkeit, das Steuerelement eine POST Anfrage machen zu lassen.

Da ich sowieso schon auf Stackoverflow das Beispiel gefunden hatte, habe ich mir gedacht, dass ich das auch direkt dort frage, auch wenn es leider bisher keine lösenden Antworten gegeben hat: https://stackoverflow.com/questions/...69770#58869770

Deswegen habe ich mir gedacht, dass ja eventuell hier jemand den Durchblick hat und mir helfen kann:

Ich will das IWebViewControl Interface um diese procedure erweitern:

Code:

procedure NavigateWithHttpRequestMessage(requestMessage: IHttpRequestMessage); stdcall;

Dazu brauche ich jedoch jetzt das IHttpRequestMessage Interface, das ich mir im Windows 10 Kit rausgesucht habe:

Code:

[exclusiveto(Windows.Web.Http.HttpRequestMessage)]
[uuid(F5762B3C-74D4-4811-B5DC-9F8B4E2F9ABF)]
interface IHttpRequestMessage : IInspectable
{
[propget] HRESULT Content([out] [retval] Windows.Web.Http.IHttpContent** value);
[propput] HRESULT Content([in] Windows.Web.Http.IHttpContent* value);
[propget] HRESULT Headers([out] [retval] Windows.Web.Http.Headers.HttpRequestHeaderCollection** value);
[propget] HRESULT Method([out] [retval] Windows.Web.Http.HttpMethod** value);
[propput] HRESULT Method([in] Windows.Web.Http.HttpMethod* value);
[propget] HRESULT Properties([out] [retval] Windows.Foundation.Collections.IMap<HSTRING, IInspectable*>** value);
[propget] HRESULT RequestUri([out] [retval] Windows.Foundation.Uri** value);
[propput] HRESULT RequestUri([in] Windows.Foundation.Uri* value);
[propget] HRESULT TransportInformation([out] [retval] Windows.Web.Http.HttpTransportInformation** value);
}

Wenn ich das richtig verstanden habe, ist das die (teilweise) Übersetzung:

Code:

IHttpRequestMessage = interface(IInspectable)
  ['{F5762B3C-74D4-4811-B5DC-9F8B4E2F9ABF}']
    procedure Placeholder_ContentGet; safecall;
    procedure Placeholder_ContentPut; safecall;
    procedure Placeholder_HeadersGet; safecall;
    procedure Placeholder_MethodGet; safecall;
    procedure Placeholder_MethodPut; safecall;
    procedure Placeholder_PropertiesGet; safecall;
    procedure Placeholder_RequestUriGet; safecall;
    procedure Placeholder_RequestUriPut; safecall;
    procedure Placeholder_TransportInformationGet; safecall;
  end;

Was ich nun garnicht verstehe: Wie erzeuge ich davon nun ein Objekt?

Ich habe schonmal in die TLBs von Activex DLLs reingeguckt und gesehen, dass die passenden Objekte per CreateComObject() erzeugt werden, aber wenn ich die GUID des Interfaces da rein gebe, dann sagt er mir, dass die Klasse nicht registriert wäre. Übersehe ich da etwas Offensichtliches oder bin ich vielleicht völlig auf dem Holzweg?

Vielleicht hat ja einer von euch etwas mehr Ahnung von Interfaces und kann mir zumindest die generelle Richtung weisen.

[Bernhard Geyer]

Bevor du weiter Zeit investierst: Schmeiß es weg.
MS begräbt den Edge-Browser und schwenkt auf Chromium um
D.h. diese Interfaces könnten in ein paar Monaten "verwaist" sein.

Am besten gleich Chromium nutzen
https://github.com/salvadordf/CEF4Delphi

Evtl. gibt es dann mal eine Lösung wie man den "Edge"-Chromium nutzen kann, so das man die DLLs nicht selbst in den eigenen Installer bringen muss.

[BobTheBuilder]

Ich gehe mal stark davon aus, dass man diesen "Edge mit Webkit als Basis" dann ganz normal über dieses WebView Interface nutzen kann. Dann darfst Du nämlich von CEF zum WebView schwenken.

Und es sind ja nicht mal große Bemühungen, die ich da anstellen muss. Ich muss ja nur wissen, wie das mit den Interfaces funktioniert und dann ist das Problem vermutlich in 5 Minuten gelöst. Das ist mir lieber, als jetzt Zeit darin zu investieren, eine für den Kunden und mich als Supporter angenehme Lösung mit CEF zu basteln.

[Bernhard Geyer]

Zitat:

Zitat von BobTheBuilder (Beitrag 1451384)

Ich gehe mal stark davon aus, dass man diesen "Edge mit Webkit als Basis" dann ganz normal über dieses WebView Interface nutzen kann. Dann darfst Du nämlich von CEF zum WebView schwenken.

Du gest davon aus. Du hast ja ein großes Vertrauen in MS.
Wenn man so sieht was MS in den letzten Jahren groß angekündigt hat und dann mit "War doch nichts" relativ schnell beerdigt hat.
Und eine "Edge mit Webkit" ist es auch nicht Chromium ist die Basis und die setzt auf Blink, welche mit WebKit evtl. noch ein paar leerzeilen im Quellcode gemein hat.

Und ich muss sicherlich nicht schwenken. Wir haben CEF drin und an Chromium-Ecke hat MS 0,0% Einfluss. Eher Google wenn es die Versorgung von Chromium abkappt. Dann hat aber MS (und dutzende andere Browser) ein anderes Problem.

Zitat:

Zitat von BobTheBuilder (Beitrag 1451384)

Und es sind ja nicht mal große Bemühungen, die ich da anstellen muss. Ich muss ja nur wissen, wie das mit den Interfaces funktioniert und dann ist das Problem vermutlich in 5 Minuten gelöst. Das ist mir lieber, als jetzt Zeit darin zu investieren, eine für den Kunden und mich als Supporter angenehme Lösung mit CEF zu basteln.

Als wenn ich sehe wo du gerade stehst ist das wohl ein "nicht mal große Bemühungen" darauf basierend das du noch nicht siehst welche zig anderen Interfaces noch vor dir legen werden.
Ich war auch schon mal auf der Suche ob es für Edge ein brauchbare integration gibt - Da gab es gar nix. Und Mannmonate zu investieren um da was hinzubekommen wollte ich nicht machen.
Chromium war in einen Tag eingebaut. Dann noch 1-2 tage und wir hatten auch erste Anbindungen an den HTML-DOM realisiert.

[BobTheBuilder]

Unser Anwendungsfall beschränkt sich darauf, den Login per POST zu realisieren. Daten kommen per lokalem HTTP Server und hook-URL zurück. Ich brauche also tatsächlich nur diese eine Funktion und bin glücklich.

[BobTheBuilder]

Falls irgendwann jemand auf das gleiche Problem stößt, wie man Interfaces von WinRT oder auch Com richtig benutzt:

So könnte zB das Interface der HttpRequestMessage aussehen:

Code:

  [WinRTClassNameAttribute('Windows.Web.Http.HttpRequestMessage')]
  IHttpRequestMessage = interface(IInspectable)
  ['{F5762B3C-74D4-4811-B5DC-9F8B4E2F9ABF}']
    procedure Placeholder_ContentGet; safecall;
    procedure Placeholder_ContentPut; safecall;
    procedure Placeholder_HeadersGet; safecall;
    procedure Placeholder_MethodGet; safecall;
    procedure put_Method(value:IHttpMethod); safecall;
    procedure Placeholder_PropertiesGet; safecall;
    procedure Placeholder_RequestUriGet; safecall;
    procedure put_RequestUri(source: IUriRuntimeClass); safecall;
//    procedure Placeholder_TransportInformationGet; safecall;
  end;

Wichtig ist, dass das WinRTClassNameAttribute mit dem aus der header-Datei oder der .idl übereinstimmt und dass natürlich die UUID auch passt.

Alle Methoden, die man nicht braucht, die aber vor den benutzten Methoden stehen, muss man trotzdem als Platzhalter anlegen. Ich hatte hier jetzt nur mit put_Method und put_RequestUri ausprobiert. Die beiden funktionieren aber wie gewünscht. Die Namen der Methoden sind gleich derer in der header-Datei. In der .idl werden die aufgrund von Schlüsselwörtern weggelassen. Also immer schön die Namen aus der header-Datei benutzen.

Wie bekommt man davon jetzt ein Objekt? Mit folgender CoClass:

Code:

THttpRequestMessage = class(TWinRTGenericImportI<IHttpRequestMessage>)
  end;

Hätte ich keine Tomaten auf den Augen gehabt, hätte ich gesehen, dass genauso auch die TWebViewControllProcess Klasse erstellt wird.

Diese THttpRequestMessage kann man jetzt ganz normal vor dem Aufruf von NavigateWithHttpRequestMessage mit .Create erstellen und so befüllen, wie man das für Richtig hält.