This is installed via Windows Update for Windows 7 machines, no? This machine is fully updated.
I had the same thought though, so I’ve also tried including the c++ package .dlls with the built app. Same problem.
I also tried manually installing the redistributable package, but it acted as though it had already been installed.
Is there a reliable way I can verify that the package has been installed?
Also, note that if I start a new project in Xojo on the same machine, add an HTML Viewer to Window1, set its Renderer property to WebKit, and on the open event of the window have that viewer open the google homepage, everything works fine.
One other piece of data on this: I’ve been trying to build this app as a 32bit executable for Windows in all my prior releases and in this release cycle so far. On a whim, I tried building it as a 64bit executable instead, with the optimization set at default (as opposed to aggressive or moderate). This crashes the IDE during the linking stage.
Interestingly: If I compile on my mac with a Win 64bit target, normal optimization, all the problems with the missing libcef etc go away, and the app seems to run properly. (I have not done full regression testing on it, but the immediate errors it was throwing when compiled for 32bit disappear.)
Its worth repeating that projects and code sent to us as part of a feedback case is always handled as if it was under NDA
Just in case anyone was nervous about doing this
Attach it privately to a report and we will do what we can to diagnose the issue and dispose of your code / project afterwards
Since you say this is only on one machine it has to be something about the config of that machine
I have seen updates NOT be completely installed - but I’m not sure there’s an easy way to know this has occurred.
Uninstalling the update, restarting then reinstalling the update often helps.
And then updating to make sure no outstanding updates exist.
Do you use an installer to set up your app ?
Installers often have a mechanism to install something like the VC Runtimes selectively when on Windows 7/8/8.1
The runtimes are part of Windows 10 so you would not need to install them there.
Ok, here is what I’ve done: First, I verified that I did indeed have an msvcp120.dll in windows/system32. I then installed BOTH the x64 and x86 versions of the redistributable library from the link in the post above (https://www.microsoft.com/en-us/download/details.aspx?id=30679). (64 bit first, because this is a 64bit version of windows, then 32 bit because I’m building a 32 bit app, and I’m not clear which version I actually should be using). Regardless, after installing both, the app still crashes with the same complaint about not being able to find the libcef.dll when run from the debugger and when run as a built app.
I then followed your suggestion to move the .dlls from the app’s Lib directory up one level to be siblings of the application, et voil - the app launches correctly and the webkit-based browsers all seem to work correctly.
Is there something about the path where I’m running this on this computer that could cause the issue?
Is there some other reason it is not looking in the libs directory?
The path of the project on disk is:
C:\Users\kimball\Documents\AcuGraph\AcuGraph\Source5.0\AGSource\AcuGraph 5.0.xojo_project
The debugger builds into a directory as a sibling of the project:
C:\Users\kimball\Documents\AcuGraph\AcuGraph\Source5.0\AGSource\Builds - AcuGraph 5.0.xojo_project\Windows\AcuGraph 5
And the binaries are built in a directory that is a sibling of the project:
C:\Users\kimball\Documents\AcuGraph\AcuGraph\Source5.0\AGSource\Builds - AcuGraph 5.0.xojo_project\Windows\AcuGraph 5
Could it be something really stupid like a . in the path name? (in the directory Source5.0)
It does not seem to be related to the . in the file path - I moved the build application to the desktop (which has no .'s in the path anywhere) and tried it again - same issue. If I move the .dlls to be siblings of the .exe, then the app launches normally from the desktop.
[quote=361965:@Kimball Larsen]Ok, here is what I’ve done: First, I verified that I did indeed have an msvcp120.dll in windows/system32. I then installed BOTH the x64 and x86 versions of the redistributable library from the link in the post above (https://www.microsoft.com/en-us/download/details.aspx?id=30679). (64 bit first, because this is a 64bit version of windows, then 32 bit because I’m building a 32 bit app, and I’m not clear which version I actually should be using). Regardless, after installing both, the app still crashes with the same complaint about not being able to find the libcef.dll when run from the debugger and when run as a built app.
[/quote]
you’d need the 32 bit libs for a 32 bit app to use - which you should have ended up with given what you did
that it still crashed is odd
[quote=361965:@Kimball Larsen]I then followed your suggestion to move the .dlls from the app’s Lib directory up one level to be siblings of the application, et voilá - the app launches correctly and the webkit-based browsers all seem to work correctly.
[/quote]
This should ALWAYS work since this is the first place Windows uses for resolving dll’s in the default search path
[quote=361965:@Kimball Larsen]Is there something about the path where I’m running this on this computer that could cause the issue? Is there some other reason it is not looking in the libs directory?
[/quote]
I’m not aware of anything causing issues with the path
One way to test would be to just change the build name to use _ instead of . and see if that affects things at all
I don’t believe or expect it will as you’re far from the first person to do this
Hi Carsten - I don’t believe I am using any webkit extensions from MBS. As noted above, this issue is specific to a single Windows 7 laptop we have on hand for testing Windows builds. The issue is not present on other Windows 7 computers we use for testing, or any other versions of Windows we’ve tried. Further, the problem is not specific to the htmlViewer and WebKit, rather, that’s the first external .dll that the app tries to call into, and the .exe apparently is not finding / loading the dll’s from the Libs folder correctly. It works fine if I move the .dll’s from the Libs directory to be siblings of the executable.
And, again, I can only reproduce this on a specific Windows 7 (fresh install) laptop and this specific project. Other projects work fine.
I’ve never installed chrome, more or less on purposes because I don’t want that to solve it (I can just see myself telling a customer… “yeah, my app does not work because you have to install chrome to make it go… no, you don’t have to use chrome, just install it…” No bueno.
I believe the problem is in how the app looks for the .dll’s, not with the webkit dll specifically.
