I have an application that I primarily develop on MacOS X. Yesterday I set up a dev environment on an HP laptop with a fresh install of Windows 7. I’ve fully updated Windows, and have only installed Firefox, Xojo, and the MBS plugins I use for this project, as well as SourceTree to pull my source code over from my local Git server.
After getting all my project source onto this new little laptop, and opening it in Xojo, everything appears to be normal with the project. I then try to run the app in the debugger, and as soon as it launches I’m hit with an Exception of type HTMLViewerException, with the message “libcef.dll not found”.
After some research, I’ve determined that this is the .dll that contains the embedded version of the WebKit browser that is used when you change the renderer to WebKit on an HTMLViewer. I have a number of HTMLViewers in my app, and some use WebKit while others remain using Native. I’ve just double-checked, and the viewers that should be using WebKit are still set to do so in the IDE just as they should be.
Not only that, but if I inspect the contents of the application Library folder created when I debug the app, I see libcef.dll is being included in the folder as it should be.
Is there some environment variable or search path or something that needs to be set up to get the application to find the .dlls that have been dropped into the Libs folder?
No, that line is trying to move the left edge of MainWindow, which is my main window in the application. This is the first reference to MainWindow that the app encounters during startup, so I believe it triggers the constructor for MainWIndow, which in turn triggers about a gazillion other constructors for all the controls, etc. MainWindow has a number of different HTMLViewers in it as controls, sprinkled around on different tab/page panels, etc.
MainWindow’s Implicit Instance property is set to “On”, if that matters.
Shouldn’t matter about implicit or not
That you’re getting this error long after the control has had to be instantiated is what I find odd
You’re getting an error about something that I would say is “unrelated” to where the bug indicator is
if you look at the error and the window’s contents is the HTMLViewer in question present ?
This is very odd
I’d literally just set up a new Windows 7 64 bit VM so it was perfectly clean
Put 2017r2.1 on it and started up
Created a new desktop project 7 put an html view on it and set it to WebKit
In the open event had it open www.xojo.com
And hit run and off it went
And there is no libcef next to the exe in that case either
Well, here’s the events in the app that lead up to the error message line:
The MainWindow is not the first window that is opened. There is a little “starting up” window that appears first while the app does things like connect to the database, verify some preferences, yadda yadda. Then that window disappears and a “enter your password” window appears. Nothing further happens until the user enters a password and and submits to log in. As soon as that happens if their password is valid, there is a call to Xojo.core.Timer.CallLater(100, addressOf app.showMainWindow).
app.showMainWindow() in turn calls app.placeMainWindow(), which is the method you saw in the screenshot. All placeMainWindow() does is consult the preferences database to see where the main window was previously positioned, and attempts to set the left, top, width and height of the MainWindow to match so that the window appears where the user last ran it.
It is on the call to set mainWindow.left that the exception occurs.
There are no other threads running at the time of this exception.
This is some VERY old code, btw - the ctype conversions are no longer necessary, and there are probably some other things in this method that I could and should to to clean it up a bit… but none of that should have any bearing at all on an HTMLViewer in MainWindow.
To be clear: this method is in app, and the only reason MainWindow or it’s HTMLViewers are involved is because this method is setting the left edge of the mainWindow.
I’ve also tried creating a brand new app on this same box, similar to the way you did it. I made mine with one difference: I subclassed HTMLViewer before adding it to the window, so my window actually has an instance of myHTMLViewer, which is a child of HTMLViewer. I set the instance of myHTMLViewer in the Window1 to use the WebKit renderer, and in the open event told it to load https://google.com. It works perfectly, and includes the .dll in the Libs directory exactly the same way as my larger app.
I should note: Windows builds that I compile on my mac and then either remote debug on windows computers or copy over there manually and run work just fine. I only set up Xojo on this laptop because it takes FOREVER to remote debug this application from Xojo on my mac. The compiled version is hundreds of MB large, and I’ve whined at you about how long remote debug takes to transfer the debug app in the past. Was hoping to save code/debug cycle time with this approach.
hmm ok so this IS the first access to MainWindow then ?
and that should cause the implicit instance to get created
which then makes sense why you get the error exactly here - trying to create the viewer it can find the dll and boom
While I’m waiting for that remote debug to start - I come from a pretty heavy linux/OS X background, and have not used Windows as a full-time OS since … well…15ish or more years.
How does Windows know where to go to find the .dlls it should use? Are there search paths or environment variables that I can to verify somewhere, similar to the $PATH in linux/OS X?
Well IF they are required at app startup (like the ms vc runtime ones) then Windows locates them using its search path https://msdn.microsoft.com/en-us/library/7d83bc18.aspx
So we dont have a lot of choices about where those must go
Either right next to the exe OR use the installers & install them is the simplest answer
Once installed Windows will update them as if they are part of the OS itself
IF they are ones from plugins the runtime loads those using LoadLibrary and so we can put them just about anywhere
Hence why you can have “AppName Libs” or just “Libs”
The runtime will hunt the dll down in either of those
There can be exceptions to this but we try to limit those because folks do like “clean” dirs for their exe’s
But its not always possible. Sometimes things tie our hands
Heck … have a peek inside an install of MS Office one day
More data: Running this in a remote debug session from my mac to this specific windows machine causes the same problem.
Compiling the app in Xojo on my mac then copying it to this windows machine and starting it up results in all sorts of errors and buffoonery. Here is just one of the several error messages (most were null pointer exceptions) that is popped:
So, I’ve demonstrated that other Xojo-built apps can be debugged and run successfully with this same .dll dependency from this machine. I’ve also demonstrated that this error occurs when I remote debug or try to launch a built version of the app from a mac, but only to this windows machine (though to be fair, I have not tried a different windows box since last week, but it did work fine there then).
This leads me to believe this must be an isolated problem with this specific windows computer, or possibly something is amiss with the project itself.
Is there a possibility that if I had opened this project with a beta version of Xojo, saved it, and then re-opened and ran it with 2017r2.1 that something like this could be an expected result? Feel free to move this discussion to the beta channel if that question is only appropriate there.
I know I have opened this project in betas, and saved it in betas, but I’ve tried to be careful about reverting using Git when going back to production Xojo versions. Entirely possible that I messed up, though.
So I’ve spent the morning trying to poke this with various sharp sticks to see if I can get it to behave. I’ve tried adding a new HTML Viewer instance to my main window and setting it’s renderer to WebKit, just in case there was an issue with how I’ve subclassed all my other HTML Viewer controls. That did not make any difference.
I then tried making MainWindow not be an implicit instance, which broke all kinds of things… It produced well over 900 compiler errors saying that the object MainWindow.whatever could not be found.
Is there any way that I can check the built application to see if it is set up correctly to load the .dll from the right place?
One more piece of info: I have another windows 7 test machine here in the office… when I remote debug to that machine there are no problems with the app at all. It opens the main window and shows the various HTML Viewer-based controls just as it should.
So this means there is something wrong with this fresh Win7 install.
