I'm trying to upgrade my project from EO 2015 to EO 2016, including using the new PDF generation engine.
I have a web project that worked fine with 2015 and now is running into several issues

my scenario is that i am creating an HtmlToPdfOptions object and adding my required authentication cookie to the Cookies collection, and setting the TriggerMode to manual. Then, calling HtmlToPdf.ConvertUrl and passing the url to convert, the response stream, and the options object.

First problem is that it appears that the cookies are not being sent along with the request. I've debugged into my AuthorizeCore handler for the request that comes in when i call ConvertUrl, and the cookie collection on the request does not include the cookies i added to the options object.

I can work around that, so it is no fatal, but that should work right (and would be preferrable if it did)

The next problem is fatal for me.

I created a simple unauthenticated test page that looks like so:



I added


to my setup prior to calling convert. Also set the max load time to 5 seconds

If i use TriggerMode Auto, the page converts and shows as expected. With Manual, it times out after 5 seconds, and the output of the DebugConsole is:

Source: v8/eo
Line #: 31
Severity: Error
Uncaught TypeError: (var).extInvoke is not a function


So apparently it seems that extInvoke is either not present, or whatever object it is being invoked from is not correct.

I should add that when running the page in Auto mode, i get that same error logged though the page converts fine.
If i comment out the call to eopdf.convert(), the error goes away. So i'm pretty sure that the error is originating in the eopdf.convert() call.

Any insights? I'm dead without manual triggering capability.

Well that works, but...
The eopdf.convert call now triggers my pdf creation, and that's good.

But it seems that you guys changed the javascript object from window.EO to window.eoapi, in this last build (between 42 and 49).
Or, perhaps window.eoapi has been there all along, and you just removed window.EO?

Point is, i am now finding that my use of embedding using the WebBrowser control and the window.EO object is mostly broken.

Again, this was working perfectly with build 42.

The latest help file seems to talk about window.eoapi as the object that i'm supposed to use. It seems that it replaces window.EO, but i don't see any mention of eoapi in the changelog.

So, question 1 - is it correct to use window.eopai.extInvoke or window.EO.extInvoke? It seems window.eoapi is the correct answer.


And i did get it to work a few times, but only by putting some random statements like:

console.log('eoapi: ' + typeof window.eoapi)

throughout my code. some of these messages are in the base MVC view file, some are inline in js files and some are in $(function(){}) blocks within these js files.

A couple of times, it has worked and my page loads. Most times, it hangs.

I think it's a timing thing, like somehow window.eoapi is being initialized asynchronously somehow and sometimes i get it at the right time and sometimes i don't.

Can you speak to any of this?

build 49 is pretty unusable from an embedding standpoint.

you miss my point. the question isn't about eopdf vs eoapi.
it is about EO vs eoapi for embedding situations using the WebBrowser control. Nothing to do with PDF.
Worked before 49. Doesn't work now.

Well, what i can say for sure is that with build 42, all was swell (except for eopdf.convert) and with build 49 the startup of the web browser component is 50/50 at best. Probably more like 20/80 failing.

I don't think it is the eoapi or eoWebBrowser or EO object anymore as I am seeing the exact same behavior when loading my pages (referencing the eoapi object) and also for a simple page like http://google.com

I am hooking up the ConsoleMessage event on my webView object prior to loading anything. When it works i get all the messages. When it doesn't, i don't get any messages.
So, in other words, the entire JS runtime environment seems to be disconnected from the WebBrowser control when it fails.

It also seems to be timing related. If i run under a debugger, it usually, but not always works. When i run normally, it sometimes works, but usually does not.


I captured some output from dbgview.
I see the pretty much the exact same messages for 3 cases - 49 where it works, 49 where it fails, and 42 where it (always) works.
At the bottom of this post is the output for build 49 when it fails.

The way i launch the browser may be of interest.
On the main thread it creates a WebBrowser control and adds it as the Content property of a ContentPresenter control in my UI (which is one tab item in a tab control)
I then call LoadUrl on the browser object's WebView and capture the loadTask result, which i wait for on a background thread by calling
loadTask.GetDoneEvent().WaitOne()

When it fails, WaitOne call never returns.


So, i say again. Something changed between build 42 and 49 that is causing the EOWebBrowser control to mostly not work.
There can't be that many changes at this level. Please take a look back and see what might be impacting this.




[9108] SHIMVIEW: ShimInfo(Complete)
[9108] eo.init.pid = 9108
[9108]
[9108] init done
[9108]
[9108] RDMAlert:EO_ImageManager
[9108]
[18048] SHIMVIEW: ShimInfo(Complete)
[18048] Pipe client connects to \\.\pipe\eo.ipc.im.pipe.v16.0.49.0_1, m_hPipe = 24, error = 0
[18048]
[18048] Failed to register window class. error = 1410
[18048]
[18048] eo.init.pid = 18048
[18048]
[18048] init done
[18048]
[20904] SHIMVIEW: ShimInfo(Complete)
[18048] Create server pipe \\.\pipe\eo.ipc.temp.24128.1.1, m_hPipe = 1528
[18048]
[18048] Create server pipe \\.\pipe\eo.ipc.temp.24128.1.1, m_hPipe = 1552
[18048]
[20904] Pipe client connects to \\.\pipe\eo.ipc.im.pipe.v16.0.49.0_1, m_hPipe = 40, error = 0
[20904]
[18048] Create server pipe \\.\pipe\eo.ipc.temp.24128.1.1, m_hPipe = 1576
[18048]
[20904] Failed to register window class. error = 1410
[20904]
[20904] eo.init.pid = 20904
[20904]
[20904] init done
[20904]
[22688] SHIMVIEW: ShimInfo(Complete)
[22688] Pipe client connects to \\.\pipe\eo.ipc.im.pipe.v16.0.49.0_1, m_hPipe = 24, error = 0
[22688]
[24128] L4N: INFO 2016-04-11 09:38:08,734 [PID:-1][24128][1] - LoadUrl:webView.LoadUrl : http://localhost:9000/forms/ZzzhBJ44zoYHtLmNQhfRhcZCRn8Do8xW$O0qrk1kcdk_
[24128] L4N: INFO 2016-04-11 09:38:08,735 [PID:-1][24128][7] - LoadUrl:webView - wait for GetDoneEvent
[22688] Failed to register window class. error = 1410
[22688]
[22688] eo.init.pid = 22688
[22688]
[22688] init done
[22688]

So far, i have not been able to reproduce the behavior in a simple test project.
So, i am very hopeful (desperate you might even say) that you will be able to identify something that changed between 42 and 49 that would account for this new problem.
I'll keep trying...

One thing that would be a great improvement, if possible in working through this, would be to eliminate the requirement that the component be visible when LoadUrl is called. I'd really like to be able to render the component as Hidden (with it's correct size) then when i get a call from an embedded JS method that my page extInvoke's i would like to make the browser component visible. The point of this would be to allow me to put up a spinner or some other content in WPF during the somewhat long time that the browser is initializing. Especially the first browser instance created by the process. I've experimented with this in the past and it seems to work most of the time, though i occasionally just get a black hole where the browser is supposed to be.

I would stress that i am not doing any of that here. I have a case where the browser is created and visible immediately prior to calling LoadUrl and that is what is hanging in 49. Just not in my test project so far.

Thanks

Ok, thanks for that explanation. It makes sense, and i can replicate and control that behavior in my test project, and when we get this working, in my real project too.
So that's progress:)

But to emphasize that that does not resolve the issue here. I have a case where the component is parented and visible when LoadUrl is called, and it hangs.
From the changelog notes for build 49, it seems to me like some of the changes around deadlocking may whack-a-moled the problem up over here now.
Just guessing. I can't really tell if the component is deadlocked or what.

I can say this though, when i use a non-licensed version of the component in the test project, and i do LoadUrl prior to adding the component to the tree, and it doesn't show (as expected) it does not show the license warning window in the lower right of the screen.

Whereas, in my real project with a fully visible and parented control, when using no license, and it hangs, the license warning window does show up. So I think that is telling me that it is getting further along in the process before getting stuck, and the problem is not so much with the window parent.

Hope that made sense.
Waiting for news....
Thanks.

This seems to have resolved my issue. Thanks.

I am receiving the "Uncaught TypeError: (var).extInvoke is not a function" message when I have the conversion set to manual.
I am using the newest 2016.0.55.0 version as well.

I am calling window.eoapi.convert but the pdf is never generated.

Either one I call results in the same issue.

It turns out that I was getting this error because I was using the call to eopdf.convert inside a setTimeout. So I had code that looked like setTimeout(window.eopdf.convert, 2000).

When I took out the timeout everything started to function correctly.