I have been working with TEdgeBrowser/WebView2 and an installed version of the Edge Beta/Canary browser version as the "runtime" which seems to work fine. However for production rollout we would greatly prefer to ship the fixed version of the runtime from within our application directory.
I have been attempting to use the following:
MyEdgeBrowser.BrowserExecutableFolder := ExtractFileDir(Application.ExeName) + '\WebView2Runtime';
Within the above referenced path I have the msedgewebview2.exe with the full installation of the fixed version runtime and all supporting files & folders. This is the file that I downloaded and extracted:
Microsoft.WebView2.FixedVersionRuntime.98.0.1108.62.x86.cab
Here's an image of what it looks like when extracted:
I have attempted to place the WebView2Loader.dll in my app directory, in the WebView2Runtime folder, and even in the WebView2Runtime\win-x86\native folder, always as a subfolder of my application directory.
I've tried the 11/20/2021 version of WebView2Loader.dll that Embarcadero distributes with the GetIt package manager, as well as the latest and greatest versions distributed by Microsoft via the NuGet package manager.
The CreateWebView call always fails.
Has anyone successfully got the fixed version runtime to work with Delphi & the WebView2Loader.dll? Are there version specific issues? What folder structure is required?
Thanks.
UPDATE: One crappy workaround that I found was to install a dev or canary version of Edge, then copy all of the files from the "C:\Program Files(x86)\Microsoft\Edge Beta" folder into my app folder, uninstall Edge Beta/Canary, then point the BrowserExecutableFolder to the "Edge Beta\Application<version #>" folder. This is the first time I've seen a "fixed version runtime" function without an Edge or Canary install.
I had started the project in 64-bit mode but for internal reasons had to switch to 32-bit mode. Unfortunately I had not switched back to the 32-bit version of WebView2Loader.dll, but was using the 32-bit version of the runtime.
Once I switched to the 32-bit version of WebView2Loader.dll the TEdgeBrowser was able to work with just the fixed version runtime, no further installation required.
Related
I tested TEdgeBrowser in RAD Studio 10.4.2 Sydney. Dropping the component onto a Form in C++Builder and then calling:
EdgeBrowser1->Navigate("https://www.stackoverflow.com/");
This results in an error on my development machine:
Failed to find an installed WebView2 runtime or non-stable Microsoft Edge installation.
I have placed WebView2Loader.dll (from C:\Program Files (x86)\Embarcadero\Studio\21.0\Redist\win32\) into the project's executable folder, so that could not have been the cause of the error.
After that, I installed Edge Canary, and then it started working without errors.
However, if I compile the same project in Release configuration, and then run on another system which only has a stable installation of the Microsoft Edge browser and doesn't have Edge Canary installed, it all works.
But, if I run the same Release build on my build system, it fails to load (probably because of the same reason as the Debug build - it can't find the Canary installation).
I tested TMS's TAdvWebBrowser component, which doesn't have this requirement, and it works on both systems without installing Edge Canary. But I'd prefer to use TEdgeBrowser instead, to avoid an unnecessary dependency on a third party component.
What is the reason for this odd behavior for TEdgeBrowser, and does the same happen in RAD Studio 11 Alexandria? Can this be avoided so it works with a stable Edge installation on both systems?
EDIT: I later discovered that there is this property:
EdgeBrowser1->BrowserExecutableFolder = "C:\\Program Files (x86)\\Microsoft\\EdgeCore\\101.0.1210.53";
With that, all works. But, according to the documentation (Using TEdgeBrowser Component and Changes to the TWebBrowser Component), it should automatically locate the current version of the WebView2 control on the system. It does this on one system, but not on the development system.
TEdgeBrowser requires WebView2 Runtime in order to operate. More details on MS Edge Documentation website.
WebView2Loader.dll should be loadable by your application, in the same folder, known path or registered in path environment variable. Latest version is available on NuGet. Nupkg is a zip archive. Look in build\native\ folder.
TEdgeBrowser.BrowserExecutableFolder should point to WebView2 runtime folder in case of fixed version.
Fixed version distribution, placed inside your application folder seems the preferred way on your scenario.
MS claims that evergreen version will be distributed by default in next Windows versions.
Having a hard time attempting to run an example how to use TEdgeBrowser component on Windows 10.
Using the latest RAD Studio 10.4.1 (27.0.38860.1461)
The example is located under this path:
c:\Users\Public\Documents\Embarcadero\Studio\21.0\Samples\Object Pascal\VCL\WebBrowser\Edge\
Attempting to start results in "Failed to initialise Edge browser control".
What I tried:
Installed the latest stable Edge version (88.0.705.68 (Official build) (64-bit))
Downloaded and installed the runtime from
https://developer.microsoft.com/en-us/microsoft-edge/webview2/
Downloaded this:
https://www.nuget.org/packages/Microsoft.Web.WebView2/1.0.705.50
Extracted WebView2Loader.dll and placed into the same folder where the compiled executable of the above demo resides
The documentation on:
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Using_TEdgeBrowser_Component_and_Changes_to_the_TWebBrowser_Component
Seems to be out of date and refers to old 0.9.430 version. I have actually previously used Edge Canary release with that version of WebView2Loader.dll before and that has worked, but the stable version of Edge Chromium was released in the meanwhile, assuming there were breaking API changes.
So, is it even possible to use TEdgeBrowser with Edge Chromium at this point because from all that I've tried it seems pretty hopeless? To me it looks like it is hard-coded against 0.9.430 and RAD Studio 10.4.1 wasn't updated. Is there a workaround of any sort?
for solving this copy "WebView2Loader.dll" to your output path
TEdgeBrowser requires WebView2 Runtime in order to operate. More details on MS Edge Documentation website.
WebView2Loader.dll should be loadable by your application, in the same folder, known path or registered in path environement variable. Latest version is available on NuGet. Nupkg is a zip archive. Look in build\native\ folder.
TEdgeBrowser.BrowserExecutableFolder should point to WebView2 runtime folder in case of fixed version.
MS claims that evergreen version will be distributed by default in next Windows versions.
I've uninstalled my RAD Studio 10.2.2 and installed 10.2.3 in my Win10 development VM. Along the way I uninstalled all the previous 3rd-party libs, including the Jedi GetIt packages, and per the instructions got rid of all the old Jedi source and DCP/DCLs. I'm attempting to install them back into 10.2.3 via GetIt. The JCL libs install fine, but when I try to install JVCL, the installation batch file hangs after compiling the installer and the VM comes to its knees. I rebooted, started taskmgr and watched as the batch file ran - it appears to go into a loop creating many instances of msgfmt. I've tried removing it all again, downloading and installing the 3.8 version myself and running the install batch file by itself, same problem; then backing up to the 3.6 version that had installed OK in 10.2.2, and it does the same thing. If I edit the batch file to skip the language-setup section, the batch file completes OK, but trying to re-run the GetIt update causes it to re-download and replace that batch file. :(
The installer does compile before the languages part of the batch file is reached, so I tried running the installer directly. I assume I'm not passing it cmd line info it needs, because it compiles the 64-bit libs fine but chokes immediately on compiling the 32-bit version of JvCore250.bpl with an unspecified compile error.
Anyone else run into this? Is a solution known?
Turns out to ultimately be a pathing problem. When multiple installations of the IDE exist on a machine (e.g. my VM has or previously had D2007, XE2 and 10.1 on it), the PATH environment variable can be too long - edit the PATH in the system to remove the old/stale paths. Then make sure that the library paths in the IDE includes $(BDSLIB)\$(PLATFORM)\release or you'll get "can't find RTL" when building the packages.
For me the problem is generated from the msgfmt.exe of dxgettext.
msgfmt.exe generates multilanguage messages, for a multilanguage support of jvcl installation.
For the specific problem of msgfmt.exe try to see this: dxgettext and Windows 10
I resolved the problem opened the install.bat file in jvcl folder, and I commented (with ::) every line where the msgfmt is executed.
Attention:
If you use getit I suppose you have to open the folder where jvcl is downloaded and search install.bat (I didn't use getit)
Instead I downloaded jvcl directly from github in my component folder, and I did what is written above in that folder.
I tried to install "TeeChart VCL/FMX v2018 Pro Evaluation version - Online" on a Delphi 10.2 Version 25.0.29039.2004.
Installation works fine but when I launch Delphi Embarcadero, I have errors :
Any help ?
The problem you're experiencing is caused because you aren't using the Rad Studio 10.2 Tokyo update 3 version 25.0.29899.2631 and latest TeeChart Pro VCL/FMX v2018.24 is only supported for that.
You can download Rad Studio 10.2 Tokyo Update 3 from the link below:
http://edn.embarcadero.com/article/44774
Make sure you run both the installer and the IDE with high privileges ("Run as Administrator").
Since you already installed TeeChart, you can just run "TeeInstall.exe" in the installation folder with high privileges to reinstall the components into the IDE, without having to fully reinstall the components.
Looking at the screenshots, it seems the bpls are in 2 locations (System32 and the Teechart output folder).
As I have encountered this issue too in the past, I would suggest the obvious by manually deleting the relevant teechart .bpl files from your windows system folders.
Take care to remove them from both the 32bit and 64bit system folders
- C:\Windows\System32\*925.bpl
- C:\Windows\SysWOW64\*925.bpl
as well as from the BDS folders:
- C:\Program Files (x86)\Embarcadero\Studio\19.0\bin
- C:\Program Files (x86)\Embarcadero\Studio\19.0\bin64
- C:\Program Files (x86)\Embarcadero\Studio\19.0\Redist\win32
- C:\Program Files (x86)\Embarcadero\Studio\19.0\Redist\win64
- C:\Program Files (x86)\Embarcadero\Studio\19.0\Redist\<others platforms you may use>
When deleting them ensure no delphi or one of your own apps is running as this prevents the bpls from being deleted. After doing so, teerecompile shouldn't complain anymore. So this is a "one shot" fix. After this you should be able to rely on TeeRecompile.
BTW: by removing I mean move them to a different folder rather than deleting them, so you can restore. didnt think of it as I use a VM for development and can always easily roll back.
OOPS: I overlooked the fact you cannot recompile. Nevertheless, I think the bpl removal tip still is valid.
I have a simple 3D application programmed in C++ and D3D9 using MSVC++ 2008 Express. Some weeks ago, I had to format my hard disk, so the DirectX SDK is not currently installed.
However, I found that the exe file that I found in my "Debug" folder for the project does not run. The error it gives is:
"This application has failed to start because d3dx9d_38.dll was not found. Re-installing the application may fix this problem."
Of course, it worked after I installed the SDK. Then I compiled a "release build" thinking that that was the solution. Then I uninstalled the SDK and tried to run the .exe file.
Still gave me the error.
So how does one make such .exe files run on machines without the SDK?
I think you cannot run the app without the SDK. See XBMC, which requires the SDK to run.
However, you could try simply placing the required dll file from your SDK in the same directory as the executable.
I followed the solution as stated here.
I copied the d3dx9_38.dll file into my Release folder. It still didn't work. However, I renamed the dll file to "d3dx9d_38.dll. Then it worked.
Wondering why I had to rename to the debug version of the file even though it was a RELEASE build...