Microsoft Edge - WebView2, embed web code in your native application

[Gianni]

8 hours ago, LarsJ said:

... How do we get on from here?

It would be interesting to group all of this into an include with a basic function similar to IE's _IECreateEmbedded function as a starting point. For example a _GUICtrlWebView2_Create capable of returning a $oCoreWebView2 "object" so that you can easily create one (or maybe even more than one) WebView2 on the same GUI ... sorry maybe I'm a little excited and run too fast (but at least I hope I'm not delirious )
here (https://weblog.west-wind.com/posts/2021/Jan/14/Taking-the-new-Chromium-WebView2-Control-for-a-Spin-in-NET-Part-1) is an interesting and clear reading which, while referring to the .NET environment, can also be interesting and useful for AutoIt.
Interesting are the general aspects, the comparison between the WebBrowser control vs WebView2, and the .NET examples (which would be interesting to have it for AutoIt, even if mainly it already is in the larsj's code)
Sorry if I speak only without publishing any code, but, to put it in a phrase that moderators often use on the forum, ...... See you soon with some legitimate content hopefully.

Edited February 13, 2021 by Chimp

[mLipok]

Interesting:
https://stackoverflow.com/questions/66052640/winforms-microsoft-web-webview2-navigate-page-fully-loaded
https://stackoverflow.com/questions/66024296/webview2-how-to-run-javascript-function

https://stackoverflow.com/questions/65849338/how-to-login-to-multiple-account-at-same-time-with-microsoft-webview2
https://stackoverflow.com/questions/65403022/how-do-i-get-server-response-code-in-webview2
https://stackoverflow.com/questions/65378907/how-to-post-data-with-webview2

 

Edited February 13, 2021 by mLipok

[LarsJ]

Summary of the Getting started examples
The 7z-file at bottom of this post has been updated again. All examples have been updated to make the code a little more uniform.

The Getting started version of the Scripting example has been added as WebView2-5.au3.

The Communication example has been added as WebView2-6.au3. The example still doesn't work because CoreWebView2WebMessageReceivedEventHandler_Invoke() isn't called. But the example no longer crashes. The crash was caused by the CoreWebView2WebMessageReceivedEventHandlerDelete() function in the cleanup section immediately after the main loop. This code line has been deleted.

[Gianni]

only 2 cents:
Reading this web page I have copied/pasted some information from there, to here in this larsj's snippet trying to understand something more.

; To initialize the web view we must call the CreateCoreWebView2EnvironmentWithOptions() method with the following arguments:
    ; (1) The path to the installation folder of Edge.
    ;     If this is null, the component should automatically locate the installation of Edge and use that.
    ;     In practice, providing null does not work well, and the component is not able to detect the browser.
    ;
    ; (2) The path to the user data folder.
    ;     If this is null, a subfolder in the current folder will be created.
    ;     Beware that if your application is installed in Program Files, it will not be able to create it.
    ;     Invoking this method will result in an access denied error (0x80070005 which is a HRESULT value for ERROR_ACCESS_DENIED).
    ;     Therefore, make sure you provide a user folder to a writable location.
    ;
    ; (3) Optional environment options (as ICoreWebView2EnvironmentOptions*) to change the behavior of the web view.
    ;
    ; (4) A handler for the result of the asynchronous operation, that will be invoked if the environment was successfully created.
    ;
    Local $aRet = DllCall($hWebView2Loader, "long", "CreateCoreWebView2EnvironmentWithOptions", _
            "wstr", "", _ ;         (1)
            "wstr", @ScriptDir, _ ; (2)
            "ptr", Null, _ ;        (3)
            "ptr", $pCoreWebView2CreateCoreWebView2EnvironmentCompletedHandler) ; (4)

Well, if we set the parameter (2) with a path that is convenient for us, for example @ScriptDir, we don't have to worry about enabling read/write on the WebView2 user data folder within the AutoIt path.

[LarsJ]

This DllCall should be implemented in a function that takes 4 parameters in the usual AutoIt way. Do we need other DllCall functions?

Another issue I've been thinking a bit about (so far relatively superficial) is how we handle all of these Invoke callback functions. These are some of the relatively trivial considerations I've made:

If different functionality is desired in 2 different scripts, the code in the Invoke functions may also be different. How is this handled in relation to a UDF?

If 2 WebView windows are created in the same script, 2 different sets of the Invoke function with different names may be needed. How is this handled in relation to a UDF?

So far, data has been passed to the Invoke functions as global variables. How do we avoid a myriad of global variables to pass data to the Invoke functions?

How do we generally handle all of these Invoke functions in a user friendly way in relation to a regular AutoIt programmer? The easy solution is to let the AutoIt programmer handle the callback Invoke functions himself. But it's certainly not very user friendly.

Any good ideas for handling the callback Invoke functions?

[mLipok]

  

18 minutes ago, LarsJ said:

.... Any good ideas for handling the callback Invoke functions?

.... by Creating API_ARRAY .
We should have ARRAY with GUID as first element to check if user pass proper API_ARRAY  to function.
API_ARRAY  should have enumerated elements (declared by Global Enum's ).
User should create API_ARRAY at start and use them for desired WebView2 instance/window.
If he want to have 2 separate instance/window then user should crate separate API_ARRAY variables for each WebView2 instance/window.

API_ARRAY  should be always passed to function as ByRef

The only Global variables should be enums for selecting API_ARRAY elements.

Edited February 16, 2021 by mLipok

[LarsJ]

Would you please demonstrate the technique in code based on e.g. the Navigation example with two different WebView windows in the same script.

[mLipok]

currently I'm at work.
Will do this at night.

 

[mLipok]

@LarsJ which of yours post should be pointed as a link to downolad section in my OP.

[mLipok]

On 11/12/2020 at 11:43 AM, mLipok said:

TIMELINE/ChangeLog:
 

1. 2020-11-12 - Project propsed by @mLipok
2. 2021-02-03 - First version provided by @LarsJ

Which post should be add here ? I mean to the OP.
 

[mLipok]

5 hours ago, LarsJ said:

Would you please demonstrate the technique in code based on e.g. the Navigation example with two different WebView windows in the same script.

Take a look at my WebView2_mLipok_mod.zip

Focus on changes made in:   WebView2-6.au3 + WV2Interfaces.au3

 

in:  WV2Interfaces.au3

expandcollapse popup

............
Global $WV2API_CURRENTLY_USED
Global Enum _
    $WV2API_GUID, _
    $WV2API_CORE_OBJECT, _
    $WV2API_CORE_POINTER, _
    $WV2API_SETTINGS_OBJECT, _
    $WV2API_SETTINGS_POINTER, _
    $WV2API_ENVIRONMENT_OBJECT, _
    $WV2API_CONTROLER_OBJECT, _
    $WV2API__UBOUND

............

Func _WV2API_Create()
    Local $API[$WV2API__UBOUND]

    $API[$WV2API_GUID]=$sIID_ICoreWebView2

    ; if you create new API you want to use them so it will be preset as current API
    _WV2API_SetCurrentlyUsedAPI($API)

    #REPLACMENT for  Global $oCoreWebView2, $pCoreWebView2
;~  $WV2API_CURRENTLY_USED[$WV2API_CORE_OBJECT]
;~  $WV2API_CURRENTLY_USED[$WV2API_CORE_POINTER]
    #REPLACMENT for  Global $oCoreWebView2Settings, $pCoreWebView2Settings
;~  $WV2API_CURRENTLY_USED[$WV2API_SETTINGS_OBJECT]
;~  $WV2API_CURRENTLY_USED[$WV2API_SETTINGS_POINTER]
    #REPLACMENT for  $oCoreWebView2Environment
;~  $WV2API_CURRENTLY_USED[$WV2API_ENVIRONMENT_OBJECT]
    #REPLACMENT for  Global $oCoreWebView2Controller
;~  $WV2API_CURRENTLY_USED[$WV2API_CONTROLER_OBJECT]

    Return $API
EndFunc

............

Func _WV2API_SetCurrentlyUsedAPI(ByRef $API)
    If Not $API[$WV2API_GUID]=$sIID_ICoreWebView2 Then Return SetError(@error, @extended, 0)

    $WV2API_CURRENTLY_USED = $API
EndFunc

............

 

in examples:

when you need to assign value to former Global current API:
 

; Create CoreWebView2 window object
    Local $pCoreWebView2
    $oCoreWebView2Controller.get_CoreWebView2( $pCoreWebView2 )
    $WV2API_CURRENTLY_USED[$WV2API_CORE_POINTER] = $pCoreWebView2
    Local $oCoreWebView2 = ObjCreateInterface( $pCoreWebView2, $sIID_ICoreWebView2, $dtag_ICoreWebView2 )
    $WV2API_CURRENTLY_USED[$WV2API_CORE_OBJECT] = $oCoreWebView2
    ConsoleWrite( "IsObj( $oCoreWebView2 ) = " & IsObj( $oCoreWebView2 ) & @CRLF )

 

When  you need to use former Global current API:
 

; Show WebView2 GUI
    GUISetState( @SW_SHOW )

    Local $oCoreWebView2Controller = $WV2API_CURRENTLY_USED[$WV2API_CONTROLER_OBJECT]
    ; Loop
    While 1

 

btw.
of course we can do even more, a step forward.
I mean to not use $WV2API_CURRENTLY_USED but hide them in some kind of container

 

Func __WV2_Container($Par = Default, $iError = @error, $iExtended = @extended)
    Local Static $Container = Null
    If @NumParams = 0 Or $Par = Default Then Return SetError($iError, $iExtended, $Container)
    Local $Prev = $Container
    $Container = $Par
    Return SetError($iError, $iExtended, $Prev)
EndFunc   ;==>_Storage_

 

Edited February 17, 2021 by mLipok

[mLipok]

I can even provide functions like

_WV2API_SetCoreObject() 
_WV2API_GetCoreObject()
_WV2API_SetCorePointer() 
_WV2API_GetCorePointer()
....

 

Edited February 17, 2021 by mLipok

[LarsJ]

You should add this post to your TIMELINE/ChangeLog.

You seem to be focusing mainly on the issue of global variables. The main problem is as far as I can see that the code in the Invoke functions is different from one WebView window to another depending on which functionality you want to implement. This means that it's not possible to include the Invoke functions in a UDF other than a function skeleton.

In WebView2.h there are 26 of these Invoke functions corresponding to 26 callback interfaces. Just to create a WebView window without any real functionality, 2 Invoke functions are required.

The problem we face is the same as for e.g. WM_NOTIFY message handlers for standard Windows controls e.g. the listview. Because the WM_NOTIFY message handler is different from one program to another, it's not possible to include the WM_NOTIFY message handler in a UDF. It must be coded by the AutoIt programmer in the specific situation depending on the desired functionality.

Our problem is exactly the same except that for us it's about Invoke callback functions instead of WM_NOTIFY message handlers.

[mLipok]

1 hour ago, LarsJ said:

The problem we face is the same as for e.g. WM_NOTIFY message handlers for standard Windows controls e.g. the listview. Because the WM_NOTIFY message handler is different from one program to another, it's not possible to include the WM_NOTIFY message handler in a UDF. It must be coded by the AutoIt programmer in the specific situation depending on the desired functionality.

Do you mean this problem in the following spoiler

Spoiler

 https://www.autoitscript.com/trac/autoit/ticket/2629

 

 

1 hour ago, LarsJ said:

You seem to be focusing mainly on the issue of global variables. The main problem is as far as I can see that the code in the Invoke functions is different from one WebView window to another depending on which functionality you want to implement. This means that it's not possible to include the Invoke functions in a UDF other than a function skeleton.

Not only about variables.
As for now my level of WebView2 knowledge is far far away, after you, I see a big distance of my understanding the issue, in relation to yours level of knoledge ( as so far I havent time to follow  all yours changes,  examples, and essentially articles related to WebView2 published on MSDN ).

 

Request for example

Using my modified version of WebView2-6.au3  ... please provide an example which will show the issue which you are talking about.
It will be easier to follow and diagnose, hope also easier to propose solution.

 

btw.
My modification was not complete. This was only a slight conceptual proposal.

 

Edited February 17, 2021 by mLipok

[Gianni]

My 2 cents:
Everything should be coded, as it already happens when using IE's BrowserControl, using these steps:
(as a simple example I refer to this script: https://www.autoitscript.com/forum/topic/186422-who-is-who-a-little-dragdrop-game/)
1) create a function that returns a WebView object (an object variable) in a way similar to this:

$LocalOIE = ObjCreate("Shell.Explorer.2"); Create a BrowserControl

where obviously instead of instantiating a Shell.Explorer.2 object we should instantiate a WebView2 object ($ oCoreWebView2).
This function should go into the udf

 

2) to create the callback functions we have to create these functions for each instance of the $ oCoreWebView2 object (if we create more than one) and therefore we cannot include them in an udf. Instead we could include in the udf a function to declare the callback prefixes for a passed WebView object:
For example, ObjEvent is used with a BrowserControl

ObjEvent($oAnObject, "IEEvent_", "HTMLTableEvents2")

where we declare the object to which we want to associate the callback functions; The "prefix", which is the "string" with which the name of the callback functions in our script must begin followed by the name of the event they must handle; and finally the reference to the interfaces valid for each $ oCoreWebView2 object

so, for example, if we create 2 (or more) WebView2 objects in a GUI where one is called $oWebView_1 and another is called $oWebView_2;
then we declare the prefix for the callback functions (I use ObjEvent here, but an equivalent function should be used and go in the udf for the WebView2 objects):
ObjEvent ($ oWebView_1, "WebView_1_event_", "WV2interfacesRef")
ObjEvent ($ oWebView_2, "WebView_2_event_", "WV2interfacesRef")
and finally we create separate callback functions for each event we want to capture, for example an "Invoke" event (of coures the "Invoke" event must exists in the "WV2interfacesRef")
WebView_1_event_Invoke (); called by events from $oWebView_1
WebView_2_event_Invoke (); called by events from $oWebView_2
These functions must be "handwritten" in our script and cannot be included in the udf.

So, more or less, just 2 main functions should go into the udf for example: WebView_ObjCreate and WebView_ObjEvents

correct me if I'm wrong, but it seems to me that the mechanism used in these LarsJ's scripts for the WebView2 is more or less the same (just a little "HardCoded") ....

I haven't been able to create a "proof of concept" script yet, but if I can I will post it here.

I'm trying to understand in more detail how LarsJ script works (it's not easy for me) but I think some global variables (Global $ oCoreWebView2, $ pCoreWebView2 .....) can be declared Local inside a function where used to instantiate a $oCoreWebView2 object to be returned to the caller as a new object (by calling this function we could create instantiate multiple separate and independent $oCoreWebView2 objects)
sorry for being long-winded

[mLipok]

29 minutes ago, Chimp said:

I'm trying to understand in more detail how LarsJ script works (it's not easy for me)

As I said the same in my case... I'm still far away.

[argumentum]

2 hours ago, LarsJ said:

In WebView2.h there are 26 ....

hmm, ...could the DLLs be "tweaked" to have a simpler AutoIt <> DLL interaction or DLLify the code/calls to make full use of WebView2 in AutoIt ? ( i'm clueless, this is just a question )

[mLipok]

7 minutes ago, argumentum said:

could the DLLs be "tweaked" to have a simpler AutoIt <> DLL interaction

In some sens it is possible but for now a distant in time. WIP.

Edited February 17, 2021 by mLipok

[LarsJ]

What I'm trying to say is simply that the entire WebView project is based on techniques and code that are so complicated that AutoIt programmers will not find it attractive and therefore will not use it. We run the risk that a UDF as a result of the project will simply not be used. 

[argumentum]

1 minute ago, LarsJ said:

WebView project is based on techniques and code that are so complicated that AutoIt programmers will not find it attractive and therefore will not use it.

I wonder if dummyfy is a word. Dummification ?. Simplify, yes, a subset of ..., nope.
An AutoItfication for the WebView2. So what I mean by that, is that we( I really ) would use this to:
1) make GUIs more on par with the times.
2) have some use for it ?

My point is that functions that resemble what is the IE UDF would be used ( maybe ? ).
Going overboard with each interaction as described by WebView2 may be way to complicated to follow by ppl ( like me ), hence a DLL that would do the actual heavy lifting and calls that are simple to use by the scripting community ( me ). Because, from my point of view ( without knowing or understanding ), a "creative architecture" can be developed/invented, that is relatable in usefulness for a simpletonscripter ( like me ).

...I hope all this chatter makes sense. I'd really like to have a simple to use implementation because, the life of IE is going the way of the dodo.