04-28-2021 07:41 PM
It's under the System namespace. You can find these sorts of answers by looking at the msdn documentation.
04-29-2021 10:16 AM
Thank you,
I'm not familiar with MSDN and when I open the "Assembly" drop-down menu to look for something, it seems like ... chaos!
I found that inside "System(4.0.0.0)" Assembly!
There should be some kind of filtering so that it will be easier to search for the contents / available assemblies!!!
In any case your new proposal is working much better, I had to add some "wait" functions in order to avoid the LabView freezing!
04-29-2021 10:39 AM
@GregFreeman wrote:
Edit: I removed the CLFN calls which are being used to set the DLL paths. I then copied the WebView2 DLLs and the Releases directory into C:\Program Files (x86)\National Instruments\LabVIEW 2019. This works. That means the problem is being caused by the calls that are adding paths to the DLL search path.
That call certainly could mess up things for good. You only pass in the 0x400 flag, effectively disabling the loading of application extensions from the current process directory as well as any DLLs located in system32. This disables many things in Windows and while many parts of Windows are loaded and initialized at process creation time, some parts are continually reevaluated at runtime and possibly loaded at a later time. If a Windows code section comes across such a passage, the lack of system32 and/or process directory resources to be found can be devastating. To enable them too you would have to OR all the values in that list or use the special flag 0x1000 which combines them.
Another interesting flag not mentioned in the MSDN documentation might be, LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR = 0x00000100;
This supposedly will enable Windows to search for dependencies in the same directory as where the current DLL is located that it tries to load. This flag is really meant for use with LoadLibraryEx() so it may not work for SetDefaultDLLDirectory().
04-29-2021 11:50 AM
Thanks Rolf, always insightful. I'll give this a shot and see what sort of results I get.
06-21-2021 11:41 AM
This is really interesting to read and could help a lot to interface to modern webapps by integrating them in Labview.
I will follow you progress and try to run it on my own as well.
08-18-2021 11:42 AM
I have been following your steps with the exact same block diagram that you had shared but I still cannot view the web. Could you share a simple vi in which you did this solution.
08-24-2021 11:33 AM
08-24-2021 11:39 AM - edited 08-24-2021 11:51 AM
Hoping this will be useful to others! Clearly, it needs to become a state machine to handle resize events, panel close, etc.
My "aha!" moment was finally following the instructions from the Microsoft
get nuget https://dist.nuget.org/win-x86-commandline/v5.10.0/nuget.exe
then "nuget install microsoft.web.webview2" then I could finally find the webview2 dlls
(will create Microsoft.Web.WebView2.#.#.#.# folder)
new .net container (on front panel, turn OFF autosizing and resize it?)
right click, insert .NET control
browse for Microsoft.Web.WebView2.WinForms.dll in \lib\netcoreapp3.0
expand Microsoft.Web.WebView2.WinForms
select WebView2()
09-13-2021 11:16 AM
An additional tidbit, is that for stand alone exe usage must include three dlls either in the exe root folder, \data, or \bin. The WebView2Loader.dll is in a slightly different path than the other2 and must be explicitly added to the build.
09-29-2021 07:46 PM - edited 09-29-2021 07:50 PM
This thread has been very useful, thanks.
I'm very close to getting this up and running but I have run into one snag when trying to select WebView2.WinForms.dll as a .Net Control
Has anyone had the same problem? Any suggestions on how to overcome this?