Printable View
Hi,
since yesterday, the WebView2 no longer works in the compiled exe. Everything is still ok in the IDE. Can anyone confirm that here? I use RC6.0.0.4 / WebView2Loader 1.0.790.0 and WebView2 89.0.774.45. I also tested older versions.
Greetings W. Wolf
When it works in the IDE and not in the compiled Exe -Quote:
Originally Posted by wwolf
then this might be caused by "non-matching binaries in the Exes \Bin\-Folder" -
(in case regfree loading is in place in "*.exe-mode")...
Could you check, whether the exact same binaries from the Folder where your "registered version" resides,
are in the Exe-local \Bin\-Folder?
The only other difference between IDE- and Exe-mode is (usually) the Useraccount,
the Process is running under (IDE-process runs as Admin, Exe-process as "normal User").
Olaf
W10-64 IDE ok
VB6 run as user wwolf
RC6.dll V6.0.0.1 C:\RC6\RC6.dll (it's registred here)
WebViewLoader.dll V1.0.790.0 C:\RC6\WebViewLoader.dll
6x msedgewebview2.exe V89.0.774.45 run as user wwolf
W10-64 fail
WebView2Demo.exe run as user wwolf
RC6.dll V6.0.0.1 C:\RC6\RC6.dll (not regfree loaded)
WebViewLoader.dll V1.0.790.0 C:\RC6\WebViewLoader.dll
unregister RC6.0.0.1
copy RC6.0.0.4 to C:\RC6\
register RC6.0.0.4
W10-64 IDE ok
VB6 run as user wwolf
RC6.dll V6.0.0.4 C:\RC6\RC6.dll (it's registred here)
WebViewLoader.dll V1.0.790.0 C:\RC6\WebViewLoader.dll
6x msedgewebview2.exe V89.0.774.45 run as user wwolf
W10-64 fail
WebView2Demo.exe run as user wwolf
RC6.dll V6.0.0.4 C:\RC6\RC6.dll (not regfree loaded)
WebViewLoader.dll V1.0.790.0 C:\RC6\WebViewLoader.dll
W7-64 IDE ok
VB6 run as user wwolf
RC6.dll V6.0.0.2 C:\RC6\RC6.dll (it's registred here)
WebViewLoader.dll V1.0.664.37 C:\RC6\WebViewLoader.dll
6x msedgewebview2.exe V89.0.774.45 run as user wwolf
W7-64 fail
WebView2Demo.exe run as user wwolf
RC6.dll V6.0.0.2 C:\RC6\RC6.dll (not regfree loaded)
WebViewLoader.dll V1.0.664.37 C:\RC6\WebViewLoader.dll
Try with WebViewLoader.dll V1.0.790.0 -> fail
Greetings W. Wolf
Found time to review this now - and can reproduce it on my dev-machine...
And it has nothing to do with "regfree-mode" of the RC6-Dlls - or not...
It all works (including the creation of a ICoreWebView2Environment instance) -
but the second part of the "init-sequence" - a call into the WebView2Loader.dll
-> ICoreWebView2Environment.CreateCoreWebView2Controller(hWnd, CallBackObject)
...works only in the IDE (not in the compiled Exe).
The problem is a "weird one" (seemingly has to do with "Process-Security-Settings" somehow) -
because what CreateCoreWebView2Controller (from inside WebView2Loader.dll) attempts,
is simply the "shelling" of the msedgewebview2.exe (sitting in Folder: C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.45\...)
And that "shelling" works (for some weird reason) when the hosting-process is the VB6-IDE -
but not when the hosting-process is the "compiled Exe" (whatever Exename it has).
I've tried all kind of things already on the compiled Executable, including:
- several types of Manifests (including the absolute identical one, I've applied to my VB6.exe)
- running it normally (non-elevated)
- running it as Admin
- also giving the compiled Exe a proper AppID (in Sub Main()) with: SetCurrentProcessExplicit*****erModelID
All to no avail... the "shelling" of: C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.45\msedgewebview2.exe fails -
and in turn the CreateCoreWebView2Controller-method (which initiates this shelling) will not raise a Success-Event on my Callback-Object.
What exactly is different, when the Host-Process is VB6.exe (where that "indirect shelling" of the webview2-child-process is successful),
I've not yet found out...
And what's funny is, when I open via Windows-Explorer the original Edge-Folder:
- C:\Program Files (x86)\Microsoft\Edge\Application\89.0.774.45\
I can successfully start msedgewebview2.exe there via Mouse-DblClick (resulting in a Browser-instance)
But when I go via Explorer into the Folder:
- C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.45\
I cannot start the msedgewebview2.exe successfully (there's also no error-message, nor any EventLog-Entry)
I followed up in that Folder with two additional attempts:
- starting msedgewebview2.exe from an unelevated Command-Console
- starting msedgewebview2.exe from an elevated Command-Console
Both attempts not resulting in any process-startup - and also no reported info in the Console-Window...
So the problem is not really located in "wrong Dll-Bindings" - all the WebView2Loader-methods work fine -
they simply fail, because:
- a normal compiled Exe as the HostProcess is missing some "hidden Properties" or "registry entries" (or whatever) related to security
- which for some weird reason "can be found", when VB6.exe is the HostProcess
Maybe it's a real bug (in the EdgeWebView-Evergreen-installation of version 89.0.774.45) -
not sure how recent this version is ... if the update came in the last 2 or 3 days, then chances are,
that the same problems exist also for "other languages" ...
(although VB6.exe as a working HostProcess is still "crazy", because it shows that 89.0.774.45 can work OK, "when started from some HostProcesses")
Olaf
I have exactly the same issue with Webview 2 version 89.0.774.45.
To work around it, I downloaded the "fixed version" 88.0.705.81 on https://developer.microsoft.com/en-u...edge/webview2/
After unzipping it, I copied it in a folder called "999.9.999.99" in the C:\Program Files (x86)\Microsoft\EdgeWebView\Application directory. This version is then taken by default and works perfectly
On the other hand, Olaf, on my PC, starting msedgewebview2.exe in the C:\Program Files (x86)\Microsoft\EdgeWebView\Application\ folder never does anything while it launches Edge in C:\Program Files (x86)\Microsoft\Edge\Application\ , even with a version that works with RC6
François
Thank you! But I know how to use RC6. I've been using that since RC3. The problem occurred without my intervention. There was no new version of my exe. My deployment hasn't changed. W. WolfQuote:
Originally Posted by SearchingDataOnly
Thank you very much! Works perfectly! I am surprised. Is the VebviewLoader so easy to build? Is it based on a version in the folder name? Incredibly!Quote:
Originally Posted by saturnian
W. Wolf
Works perfectly again. Thank you!Quote:
Originally Posted by saturnian
Seems the problem was found now (at the MS-side of things)...
Had to do with "Version-Info-Parsing" on the given Exe-Binary of the Host-Process...
VB6.exe itself seems to have stored its Version-Info in a way "compatible to the Edge-SubProcess-readout-method" -
whereas Version-Info-Resources, produced in a post-compile-step by the VB6-Compiler (in your own Exe) -
were having "compatibility-problems" with the "readout-method" of the Edge-environment.
Here is the proper thread for this in the github-tracker-discussions:
https://github.com/MicrosoftEdge/Web...ack/issues/850
(the cause described in the last few postings in that thread)...
Just now checking here again before pressing the send-button...
aaand yes - a fix for that is now already "rolled out" by MS
(an increase from the failing version 89.0.774.48 to 89.0.774.50)
So, everything is fine again with the "rolling-release" (from an "Evergreen-install" of the WebView2-runtime).
@Wolfgang
The "fixed version" of the runtime-package can always be "shipped" along with your Edge-based App
(to rule out such "breaking changes" in the future).
And you won't even have to put it into the "normal Edge-Install-folder" (behind \Programs x86\...) -
even a folder below your App.Path will do (if you properly point to that path in your WV.BindTo-call).
I still prefer the "evergreen-runtime" though, because it is the only way to remain "on the safe side of things" regarding security- or other patches.
Let's just hope it was a "wake-up-call at the right time", and that this "runtime-update blow-up" by MS was a one-time-thing.
The whole WebView2-Loading stuff is not yet that long "out of beta" - so a few devs at MS were probably still ticking in "test-channel-mode" -
but I think they realize now more and more, that people indeed start using it "in production-scenarios" (making them double-check before releasing something).
Olaf
Hi Olaf
Dang it, I already knew that! :confused:Quote:
Originally Posted by Schmidt
Thanks for the reminder!
It doesn't always have to be a mistake. Sudden interface changes could also be a problem. I think that's good about the fixed version. I can now decide for myself when to upgrade to the next version.Quote:
The whole WebView2-Loading stuff is not yet that long "out of beta" - so a few devs at MS were probably still ticking in "test-channel-mode" -
but I think they realize now more and more, that people indeed start using it "in production-scenarios" (making them double-check before releasing something).
W. Wolf
If you can load it in this way with late binding, I think this is the perfect solution.
dim a as excel.application
Version incompatibility errors often occur in this way.
dim a as object
set a =createobtect("excel.application")
This method does not require the office version of the system.
Hi
What question does your answer refer to?Quote:
Originally Posted by xiaoyao
The version incompatibility of the WebView cannot be resolved in this way.
Regards W. Wolf
Expect soon to be referred to a topic named "sorry,Chrome OCX,Miniblink,VB6 chromium,Chrome core only one dll" marketed as better solution for. . . everything!
This is usually the final routine of the rogue bot we have here.
cheers,
</wqw>
I see, this needs a corresponding version.Different versions of just like chromedriver. Correspond to different chromium version
No, it should be a problem with the compatibility of Microsoft's WebView version. Under normal circumstances, Olaf’s WebView wrapper always automatically uses the latest version (I haven’t tested this yet)Quote:
Originally Posted by xiaoyao
This is my program folder:Quote:
Originally Posted by Schmidt
MyApp.exe
cairo_sqlite.dll
DirectCOM.dll
RC6.dll
WebView2Loader.dll
Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86 (unzipped MS folder)
that works:
WV.BindTo cfMain.hWnd '(works with the WebView from the Program Files (x86))
none of this works:
WV.BindTo cfMain.hWnd, , "Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
WV.BindTo cfMain.hWnd, , App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
WV.BindTo cfMain.hWnd, , App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
what am I doing wrong? The same version is also in my Program Files (x86) folder. How do I have to enter the browserInstallPath argument?
Quote:
Originally Posted by wwolf
If you have only the above "blue colored" FixedRuntime-folder version (89) in your App.Path,Quote:
Originally Posted by wwolf
then neither of the red-marked calls will work of course...
But even if you'd correct that, there's a high probability that it will fail anyways in RC-6.0.0.4,
because the newer LoaderLibs expect (in case of a Userdefined RuntimeFolder), "a hint"
regarding the supported version-number (in the config-interface, I provide internally).
This "version-hint" is missing in 6.0.0.4 - but now contained in the newest upload 6.0.0.5.
With that new version - and a corrected Runtime-Path-Param like:
-> WV.BindTo cfMain.hWnd, , App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86"
everything should be fine again...
Olaf
Ok, these are my results:Quote:
Originally Posted by Schmidt
MyApp folder:
MyApp.exe
cairo_sqlite.dll
DirectCOM.dll
RC6.dll (6.0.0.5)
WebView2Loader.dll (1.0.790.0)
Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86 (folder with unzipped files from MS download)
Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86 (folder with unzipped files from MS download)
My different experimental paths
p1 = ""
p2 = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
p3 = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86"
p4 = "C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.54"
Code:
ret = mWV.BindTo(cfMain.hWnd, , px)
Results:
p1: all works, ret=1
6x msedgewebview2.exe (89.0.774.54) is loaded from p4
p2: don't works ret=0
msedgewebview2.exe is not loaded
p3: don't works ret=1 (!after .NavigateToString WV_DocumentComplete is not fired)
4x msedgewebview2.exe (89.0.774.54) is loaded from p3
p4: don't works ret=0
msedgewebview2.exe is not loaded
W. Wolf
On what WinOS do you run this?
FWIW, the code below works on Win10 in IDE and compiled
(with all 3 different Path-Variations ... using a cWidgetForm as you do):
modMain.bas
cfBrowser.clsCode:Option Explicit
Public fBrowser As New cfBrowser
Sub Main()
Cairo.SetDPIAwareness
fBrowser.Form.Show
Cairo.WidgetForms.EnterMessageLoop
End Sub
My Debug-Output for WV.GetMostRecentInstallPath() is:Code:Option Explicit
Public WithEvents Form As cWidgetForm, WithEvents WV As cWebView2
Private Sub Class_Initialize()
Set Form = Cairo.WidgetForms.Create(vbSizable, "Edge-Chromium WebView2")
End Sub
Private Sub Form_Load()
Set WV = New_c.WebView2
Dim P As String
' P = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.50.x86"
' P = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86"
P = WV.GetMostRecentInstallPath() '<- this is what I use underneath the BindTo-call, when you don't give a specific path
Form.Caption = P: Debug.Print P
If WV.BindTo(Form.hWnd, 4, P, App.Path) = 0 Then MsgBox "couldn't initialize WebView-Binding": Exit Sub
' If WV.BindTo(Form.hWnd) = 0 Then Form.Caption = "couldn't initialize WebView-Binding": Exit Sub
WV.Navigate "https://google.com"
End Sub
Private Sub Form_Resize()
If Not WV Is Nothing Then WV.SyncSizeToHostWindow
End Sub
C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.54
Olaf
Hi Olaf,
I used your code under W10-64 in the IDE and as exe.
My Debug-Output for WV.GetMostRecentInstallPath() is
C:\Program Files (x86)\Microsoft\EdgeWebView\Application\89.0.774.57
I have these folders in my app folder:
Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86 (folder with unzipped files from MS download)
Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86 (folder with unzipped files from MS download)
89.0.774.57 (copy from C:\...\Application\89.0.774.57)
P1 works with 6 instances of msedgewebview2.exe from P2Code:P1 = ""
P2 = WV.GetMostRecentInstallPath()
P3 = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.88.0.705.81.x86"
P4 = App.Path & "\Microsoft.WebView2.FixedVersionRuntime.89.0.774.54.x86"
P5 = App.Path & "\89.0.774.57"
P6 = "C:\89.0.774.57" 'copy from C:\...\Application\89.0.774.57
P2 works with 6 instances of msedgewebview2.exe from P2
P3 does not work. 3 instances of msedgewebview2.exe from P3 are started
P4 does not work. 4 instances of msedgewebview2.exe from P4 are started
P5 does not work. 3 instances of msedgewebview2.exe from P5 are started
P6 works with 6 instances of msedgewebview2.exe from P6
I think I found the problem. My App.Path is a network drive.
I've moved my App.Path with all MS-Folders to C:\ -> everything works.
I've moved my App.Path with all MS-Folders to D:\ -> everything works (second local hard drive)
I have also tested different variants with userDataFolder (App.Path, Temp-Path and without parameter). The results are identical.
Summary: App.Path can be anywhere, but the WebView files must on local hard drive saved. Maybe something is wrong with the path resolution in RC6 or in the WebViewLoader?
Good to know, it all works fine, when the Folder with the WebView2-Runtime-Files sits on a local drive...Quote:
Originally Posted by wwolf
No chance for "messing things up" in the RC6-code, because in case of a userdefined Path to the Runtime-Files,Quote:
Originally Posted by wwolf
I'm just passing this Path-String along to MS's WebView2Loader.dll (no chance for me to influence the loading-process in any way after that).
I guess that's another reason for the rule, to better "not use any Binaries from Network-Shares".
Maybe the WebView2Loader (or the upstarting edgeprocesses) have this problem only,
when the NetworkShare-location was given via an UNC-Path... so, did you test this with a "mapped network-drive" already?
What you could try from the outside, is to provide your Network-Path as a file-URI:
(for UNC-Paths the notation would be: "file:////server/folder/subfolder/...")
Mayhap this notation is more willingly accepted than "classicaly given UNC-Paths...
If you have to keep up your network-share-based App-deployment-scheme,
then a little check at App-Startup should be done, whether the Runtime-Binaries already exists in a location locally,
and if not, then just "copy the whole runtime-folder over" to such a local Runtime-location before you init the WebView.
That's not all that uncommon... e.g. we had to do such a thing for a quite large (40MB) *.chm helpfile in our Apps,
because the WinHelp would otherwise not properly startup with the HelpFile on an UNC-Path.
HTH
Olaf
Coincidence. My source code is on a NAS. This is useful because it gives me access from different computers. I really only wanted to test the optional browserInstallPath parameter and therefore copied the WebView files into this folder.Quote:
Originally Posted by Schmidt
Yes i use by default a mapped network-drive. I didn't test that with the UNC-Path. I didn't realize the problem until I started thinking about the possible differences between my test and yours. Your suggestion with GetMostRecentInstallPath made me recognize the problem. If we want to use WebView in productive systems, it is good if we recognize all dangers early on.Quote:
Maybe the WebView2Loader (or the upstarting edgeprocesses) have this problem only,
when the NetworkShare-location was given via an UNC-Path... so, did you test this with a "mapped network-drive" already?
Thank you for your support.
W. Wolf
Just found out something interesting...
Background:
What early versions of the WebView2Loader.dll did support,
was the direct referencing of the "real Edge"-Folder in the optional Runtime-Path
(instead of pointing to a Folder which contained the WebView2Runtime)
For the release versions of the WebView2Loader.dll, specifying the "true Edge-folder"
as the one which holds the runtime-binaries is failing - due to a lookup for the term:
"\Program Files (x86)\Microsoft\Edge\ "
If that is contained in the user-provided RuntimePath, then the instantiation will fail.
So, circumventing this "rule" boils down to the question:
"How to be able to give a different Path (not containing the "forbidden" snippet in it),
which nevertheless "points" to the already existing one..."
Answer: SymLinks
Below a code-snippet, which makes use of the CreateSymbolicLinkW API (available from Vista+).
cfBrowser.cls
So, the above is able, to start WebView2 against an already existing "normal Edge-installation" -Code:Option Explicit
Private Declare Function CreateFolderSymLink Lib "kernel32" Alias "CreateSymbolicLinkW" (ByVal pDstFolderLink&, ByVal pSrcFolder&, Optional ByVal IsDirectory& = 1) As Long
Public WithEvents Form As cWidgetForm, WithEvents WV As cWebView2
Private Sub Class_Initialize()
Set Form = Cairo.WidgetForms.Create(vbSizable, "Edge-Chromium WebView2")
End Sub
Private Sub Form_Load()
Set WV = New_c.WebView2
Dim EdgeSrc As String, EdgeVersion As String, EdgeDst As String
EdgeSrc = WV.GetMostRecentInstallPath("Edge", EdgeVersion)
EdgeDst = New_c.FSO.GetLocalAppDataPath & "\Edge_" & EdgeVersion
If Not New_c.FSO.FolderExists(EdgeDst) Then
'New_c.FSO.MultiFileCopy EdgeSrc, EdgeDst
Debug.Print CreateFolderSymLink(StrPtr(EdgeDst), StrPtr(EdgeSrc)), Err.LastDllError
End If
If WV.BindTo(Form.hWnd, 10, EdgeDst) = 0 Then MsgBox "couldn't initialize WebView-Binding": Exit Sub
WV.Navigate "https://google.com"
End Sub
Private Sub Form_Resize()
If Not WV Is Nothing Then WV.SyncSizeToHostWindow
End Sub
(by using a "different Symbolic PathName", which points to the original Edge-Install-Path)
The code above was mapping the original Edge-Install-Path into the local User-Directory as:
C:\Users\Olaf\AppData\Local\Edge_89.0.774.57
Side-Note... it is still not "all Roses" with the above approach, because:
- SymLink-creation (pointing into the Programs-Folder) apparently needs Admin-rights
- therefore the Code-Example worked already on the first attempt in the IDE (due to running it already elevated)
- but after deleting the SymLink-Folder Edge_89.0.774.57 in C:\Users\Olaf\AppData\Local\
- and making an additional attempt from a compiled Exe, it failed to create the Symlink (due to insufficient rights)
So, unless somebody finds a way to create a "symlinked folder" against a real Folder which sits in "Programs x86" -
only using "normal UserRights" (I had a normal Exe-manifest set at "asInvoker" in place),
the User would need to be "instructed", to run the App at least on the first attempt "as Admin".
What worked in both cases (IDE and compiled) though,
was "making a full copy" (see the bold, currently outcommented Line in above code)
Maybe somebody with more knowledge about such UserRights-topics,
can help find a solution which works without starting the compiled Exe "as Admin" once...
Olaf
Hi,
I continued to test yesterday and today so that we can get a better overview of what is possible and what is not possible.
Start from USB stick: Works. SecondsToWaitForInitComplete must not be too small. But I had no problem with the default of 8 seconds. So Regless Stickware should work. I think CD-ROM will work, but I haven't tested it.
Start on a different network (Windows server with Active Directory. My NAS from yesterday has Linux). That doesn't work. However, three instances of msedgewebview2 are loaded and the application shows the browser window with an error message: There is a problem on this page. An Update switch does nothing.
I also want to work with the EverGreen variant as standard. But if someone doesn't want to install this or as a fallover, an alternative solution is always nice. We already know a lot about what's going on.
I did my tests today on W7-64.
I couldn't test the SymLink method today because I don't have an edge installation here (and I don't want to do one).
I also did.Quote:
Originally Posted by wwolf
I figured out, that any path stops binding, also WV.GetMostRecentInstallPath
Code:40 Set WV = New_c.WebView2 'create the instance
50 webviewpath = WV.GetMostRecentInstallPath()
60 Debug.Print webviewpath
70 If WV.BindTo(picWV.hWnd, 8, webviewpath) = 0 Then MsgBox "couldn't initialize WebView-Binding 1": Exit Sub
What's the output of:Quote:
Originally Posted by WZabel
?New_c.Version
when you execute it in your ImmediateWindow?
Olaf
6.0.4Quote:
Originally Posted by Schmidt
Please download and install 6.0.5 (I've commented about the failing 6.0.4 in #18).
Olaf
Attention: on your page there is still 6.0.4 even if the download already contains 6.0.5.Quote:
Originally Posted by Schmidt
W. Wolf
Thank you Olaf, your update does the trick.
Now there is my next question: How can request-headers be changed?
It looks as it has to be done when the 'NavigationStarting' event is fired. But there is no such event....
Robert
The new WebView2Loader-Dlls already have interface-extensions for theQuote:
Originally Posted by WZabel
TypeLib-defined ICoreWebView2-interface (two of them):
-> interface ICoreWebView2_2 : ICoreWebView2
-> interface ICoreWebView2_3 : ICoreWebView2_2
And ICoreWebView2_2 comes (among others) with the new method:
HRESULT NavigateWithWebResourceRequest([in] ICoreWebView2WebResourceRequest* request)
Here is the Interface-Def for the new ICoreWebView2WebResourceRequest
(a "Data-Object", which needs to be passed into the above new method)...
I plan to incorporate support for that kind of "fully user-defined Request" into one of the next releases.Code:[uuid(97055cd4-512c-4264-8b5f-e3f446cea6a5), object, pointer_default(unique)]
interface ICoreWebView2WebResourceRequest : IUnknown {
/// The request URI.
[propget] HRESULT Uri([out, retval] LPWSTR* uri);
/// Sets the `Uri` property.
[propput] HRESULT Uri([in] LPCWSTR uri);
/// The HTTP request method.
[propget] HRESULT Method([out, retval] LPWSTR* method);
/// Sets the `Method` property.
[propput] HRESULT Method([in] LPCWSTR method);
/// The HTTP request message body as stream. POST data should be here. If a
/// stream is set, which overrides the message body, the stream must have
/// all the content data available by the time the `WebResourceRequested`
/// event deferral of this response is completed. Stream should be agile or
/// be created from a background STA to prevent performance impact to the UI
/// thread. `Null` means no content data. `IStream` semantics apply
/// (return `S_OK` to `Read` runs until all data is exhausted).
[propget] HRESULT Content([out, retval] IStream** content);
/// Sets the `Content` property.
[propput] HRESULT Content([in] IStream* content);
/// The mutable HTTP request headers
[propget] HRESULT Headers([out, retval] ICoreWebView2HttpRequestHeaders** headers);
}
Olaf
This sounds great.
So I will wait patient for new releases.
Thank you!
Robert
Good news: Microsoft is auto-installing the Windows 10 WebView2 Runtime
https://www.bleepingcomputer.com/new...view2-runtime/
W. Wolf
Hi Olaf,Quote:
I plan to incorporate support for that kind of "fully user-defined Request" into one of the next releases.
is this still current or even in the works?
Greetings W. Wolf