|
|
Rank: Advanced Member
Groups: Member
Joined: 2/15/2014
Posts: 52
|
Hi
I understand that EO.WebView can communicate with Javascript using its own proprietary syntax.
We have application written in C# and uses .NET WebBrowser. So javascript uses window.external.xxx to communicate with .NET app. So if we are to use EO's Webview, there's a substantial re-factoring, the javascript itself and the .NET app because right now, the C# app is written as simple as writing a public function and property. With EO, it's not so straightforward.
Would it be possible for EO to support similar syntax and design as the .NET WebBrowser control?
Thanks
Philip
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
I believe it's technical possible to support that to a certain degree. the IE interface is built on top of COM: both the .NET side objects and the browser side objects are COM objects, so they talk through COM. Chrome internal objects are not exactly COM objects. So while it is easy for us to access .NET side object through COM interface, it is not so trivial for the .NET side objects to access Chrome side objects the same way. This makes it very easy to support calls such as window.external.someFunction() but makes it difficult to support window.external.someFunction(someBrowserObject). The difference between the two is the later is passing a browser side object into the .NET side. It will be functional, as we do allow you to pass browser side objects into the .NET side (through JSObject), but it does not work exactly the same as COM based IE objects. As such we are still hesitating on mimicking this specific IE interface because you would still need to change some code anyway. In the long run, if we can implement code to dynamically wrap our browser side objects as COM object then it will be possible for us to support such interface with very minimum code changes needed on your end.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/15/2014
Posts: 52
|
HI admin,
when you say, "In the long run, ..." does it mean there is plan or it's under the pipeline? Does it mean also there's similar request from other people to support window.external for easier migration from .NET WebBrowser to EO.WebView?
Thanks.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
Yes. We do have similar request, not in the sense of mimicking IE's interface exactly, but to make it easier for transiting from IE based code. However this requires a thoroughly and systematic review of both interfaces, so while it is on our list, we do not expect it to occur in the near future. It will probably be in our next major release.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 2/15/2014
Posts: 52
|
That's good to hear. Can i request to be informed when this becomes available? We really want to move away from IE and go with webkit and this WebView is the closest and most complete .NET webkit browser control i have seen except for the interface between .NET and JS as it requires a lot of code refactoring on both javascript and C#.
One curious thought, Google mentioned early last year that they will fork out the webkit and build their own engine (Blink, i think) for Chrome. I don't know what has happened to it but in the event that Chrome uses its own engine, what will happen then? Will you stick with Webkit or follow Google?
Thanks.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,196
|
Hi,
You will receive an email from us when we have a major update. So when you receive the email, you can check the change logs or documentation to see if this has been implemented.
Chrome (as well as EO.WebBrowser) is already using blink now. But it's not really a new engine. It's a fork. Which means that pretty much everything there is still WebKit, just with new changes/wrappers introduced gradually. We will be following the Chrome/blink line since the exactly reason for Google to have a fork is because Google has realized that it's very difficult to follow WebKit as the project evolves since WebKit starts to have features that Chrome doesn't use and Chrome wants to add features that WebKit doesn't use. As such having a fork enabling Chrome developers to simply the code base.
Thanks!
|
|