I want to use OL3-Cesium to display the globe view in my WPF application using WebBrowser control.
The sample html file works fine in my IE 11 browser, but if I run the same file through WebBrowser control it gives a error saying that 'The browser supports WebGL but initialization failed' in Cesium.js.
I made my WPF application compatible with IE 11 by editing key in local machine in registry , but still it did not work.
Please help me out with some solution.
You mention making WebBrowser work more like IE11 using a registry key, but you probably need more than one. In particular:
FEATURE_BROWSER_EMULATION is needed to get IE11 compatibility and access to the WebGL API it provides
FEATURE_GPU_RENDERING is needed to enable hardware-accelerated 3D in the embedded window.
Note that Cesium uses failIfMajorPerformanceCaveat by default, which means that if GPU rendering isn't available, Cesium prefers to fail rather than try to run with software rendering. This can be overridden, but results are predictably bad, so use the GPU registry key instead.
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION
"MyApplication.exe" : REG_DWORD = 11
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_GPU_RENDERING
"MyApplication.exe" : REG_DWORD = 1
Here's a great article that explains how to use these registry keys and embed WebGL apps:
http://zett42.de/software/2013/04/04/performance-issue-of-embedded-ie-browser-control-and-how-to-fix-it/
I also had the same problem. Almost all suggested solutions involved setting FEATURE_BROWSER_EMULATION to the current installed version of IE, but Cesium would still return the error The browser supports WebGL but initialization failed
What worked was turning off compatibility mode completely.
SetBrowserFeatureControlKey(
"FEATURE_BROWSER_EMULATION",
fileName,
00000)
And of course still turning on FEATURE_GPU_RENDERING
SetBrowserFeatureControlKey(
"FEATURE_GPU_RENDERING",
fileName,
1)
Related
In my c# code, I'm working with Selenium version 3.4.
When working with the Chrome browser, the FindElemnt seems to be executed fast compared to IE11. Seems that the FindElemnt method faces some slowness when working with IE11.
Any suggestions??
Ensure you are not using the 64-bit version of the IE WebDriver. It appears to be a known issue. Based on this question there may be some ways to speed up the 64-bit version but I personally have found the 32-bit version to be more reliable.
Info on the underlying issue can also be found in this thread
After investigation of this issue, I have been able to debug the C++ code of the 64-bit
IE driver to determine the root cause. When you are running IE 10 or higher on a 64-bit
version of Windows, by default the process which hosts the containing window that includes the browser chrome (address bar, navigation buttons, menus, etc.) is a 64-bit process.
The process which hosts the window where content is actually rendered (within each
tab) is a 32-bit process. By default, the IE driver attempts to use a windows hook on the content-rendering window to make sure that a key-down message is properly processed before sending a key-up message. This is where the problem is. The windows hook is not installed, because a 32-bit process (the content-rendering process) can't execute 64-bit code. The only way to properly fix this will be to create a second (32-bit) executable to perform the wait for the key-down to be complete. Since this would amount to a massive
rearchitecture of the IE driver's binary components, no timeline is (or will be) available for this change.
Some notes. Careful readers will have already realized that this means that even when
you are running 64-bit Windows, you're likely using a 32-bit version of IE to render
the content. This is a powerful argument for continuing to use the 32-bit version of
the IE driver for IE 10 and above: you're not actually running against a 64-bit version
of IE.
If you insist that you must run the 64-bit version of IEDriverServer.exe, you have
two possible workarounds. First, you can disable native events by setting the "nativeEvents" capability to false using whatever mechanism your language binding provides for this. A more accurate workaround from an input simulation perspective would be to enable the "requireWindowFocus" capability, though this also has a windows hook dependency, which may manifest in other ways.
by james.h.evans.jr on 2014-01-31 19:23:06
Even using the 32-bit version, the IE driver is still significantly slower running the same tests as a Chromium based browser. I have had to add Waits due to the longer page load times using the IE Driver.
I'm trying to pin an exe to taskbar in windows 10. But I'm not able to find verb for pin/unpin to taskbar.
I have tried the same code on windows 7 and 8.1 machine, its working fine, but its not working on windows 10 machine.
VB Code:
Dim ShellApp, Desktop
ShellApp = CreateObject("Shell.Application")
Desktop = ShellApp.NameSpace("C:\ProgramData\ABC.exe").Parsename("ABC.exe").invokeverb("taskbarpin")
This issue was reported already (see also SO question).
And one possible solution (on the same page, re-posting it here):
Posted by Misha Rudiy on 11/5/2015 at 7:30 AM
For new OS installs you can still pin to the taskbar via the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TBDEn registry key.
Example: In an SCCM Task Sequence, I have a batch script that runs after the "Setup Windows and Configuration Manager" step that basically contains reg-adds.
Syntax (REG ADD "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\TBDEn" /v SBOEM0 /t REG_EXPAND_SZ /d "%%ALLUSERSPROFILE%%\Microsoft\Windows\Start Menu\Programs\Mozilla Firefox.lnk" /f)
You can add additional links by adding values and incrementing SBOEM0 to SBOEM1 etc.
Thanks to Wayne Ye http://www.codeproject.com/Articles/185512/Programmatically-PIN-shortcut-onto-Taskbar-on-Win7.aspx for pointing this method out back in 2011.
Somethings to note, there seems to be little public documentation on this. It most likely only works as a post imaging step (see my reference to SCCM), but I am not 100% sure. The above mentioned site states that it takes place during the DASH process. I wasn't able to find any documentation on how\when a DASH process works with Windows OSes. This may be information that is only privy to OEMS.
I'm developing an MVC app.
If I (on my Surface Pro) goes to http://www.whatbrowser.org/ it correctly says IE 10.
But if I go to my MVC app and print out the Request.Browser.Version, it returns 7.
Any idea why? Is Request.Browser.Version broken?
Thanks
Some of this is touched on in Detect Internet explorer browser version problems.
Last I knew Request.Browser uses the *.browser files that come with the installs of ASP.NET, and easily get out of date. Microsoft releases updates to them every so often, but not often enough. Currently there are some issues with webform pages breaking on IE10 without updated browser files.
Like the comments have said, browser detection is very broken. If you need to detect the browser, at the very least shy away from using the user agent string, and seriously consider why you need to know exactly what browser is used.
Request.Browser.Version doesn't always return the 'correct' browser version for IE because of many factors including compatibility view, meta tags etc.
You would be better off detecting browser capabilities instead. Further reading here: http://msdn.microsoft.com/library/3yekbd5b
As a personal preference, it would be best to detect the OS instead of the browser. Most of the common HTML5/CSS3 features are supported in IE9 and above and IE9 requires Windows Vista and up. The best way to do this using the User Agent is by checking the Trident. If there is compatibility view enabled via the browser or by using meta tags by the app itself, the wrong 'version' is returned but the Trident remains correct.
PS. This isn't fool proof but this would work most of the time.
Further reading about Trident here: http://msdn.microsoft.com/en-us/library/ms537503(v=vs.85).aspx#PltToken
Background:
I am creating system images that will be loaded onto several workstations. Windows activation will occur after the images are loaded onto the workstation. These computers will not be connected to the Internet and will be activated over the phone.
Question:
I would like to check programmatically if Windows 7 is activated or not, so that our software will not run if Windows 7 is not activated. Our software is written in C#.
The Software Licensing API - SLIAPI, take at look at SLIsGenuineLocal(). (Replaces LegitCheck)
You can run "Slmgr.vbs" on the machine and then redirect the output to check.
System.Diagnostics.Process.Start(#"cscript Slmgr.vbs > D:\\log.txt");
This will return all the information you need. Not the cleanest way to do it though.
You may check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows Activation Technologies\AdminObject\Store\TotalValidations and see if it is 1. This may not be the definative way to verify activation, but you should at least be abel to see if it was validated.
You can use this reference: https://github.com/Marko97IT/CWA
In the README.md you can find the download link.
Not sure if it applies to Win7, but I found a post that checks XP for activation using a Win32_WindowsProductActivation class.
I'll build a test one on my machine (x64 Win7) and see if it returns activated or not, but at least gives you something to try out in the mean time.
EDIT (wish I kept reading the docs) A comment on that class page mentions that this class, on Win 7 and other versions) appears to be replaced with the Software Licensing Classes. I'll see if I can get a working result.
Does anybody know if there is some sort of bug or issue with the webBrowser activex control in .NET applications, in this case the embedded browser loads a web page that depends on javascript to play music previews. It works once but if you navigate to a new page in the system it stops working.
Viewing the same site in just a normal IE browser results in no errors at all (tested on several systems of various types).
It happens on several different OS's, XP 32 and 64 bit, Vista, Windows 7.
Its also not a java applet, just jQuery and the longtail video player with some JS to bind a preview link to the player. Im very confused as to why it works sometimes but not others.
Its also a large live system and getting lots of complaints.
Let me tell you this straight up. The default rendering engine on the WebBrowser control is fixed to ensure compatibility across all platforms.
Basically, if your installed browser is IE 7 - IE 9, then the rendering engine used is IE 7.0 only (by default).
If, however, your installed IE version is IE 6 or below, then the rendering engine used is IE 4.0, unless of course you set it otherwise.
There is a misconception that WebBrowser control uses whatever is currently installed (current IE version) but this is not true, since they do this to reduce backward compatibility issues. You can see (as proof) that this really is your problem by going to http://www.whatsmyuseragent.com in your normal browser, and then going to that website again in your WebBrowser control, you will see that it says MSIE 7.0 :).
I suspect your users (and you) who are on IE 6.0 would be experiencing the problems you've alluded to since their rendering engine being used is IE 4.0 (and IE 7 if they are running anything between IE 7 to IE9). This is really bad, especially if they are on IE 6, you should ask them to upgrade their browser if they are IE 6, then, IE 7.0 will be used regardless.
I'm not sure if, when IE 10.0 comes out, the WebBrowser control's default engine will go to 10.0 (if 10.0 is installed on system of course) or if it will remain as IE 7.0 even after IE 10.0 is released, we will have to see once it comes out. However, if we guess based on previous experience, I suspect IE 10.0 will be the last version that uses IE 7.0 rendering engine, and when IE 11 comes out, the default rendering engine will remain as IE 11 for all versions of IE between IE 11 & IE 14. This is just a guess by extrapolating what they've done in the past.
You can set the WebBrowser control to use the current installed version of Internet Explorer; if you want more information on how to do this, or how to further fix the rendering engine, let me know and I'll help you out with it.
Which version of .net are you using?
Also which OS?
Ive noticed within Vista that Java applets <applet> tags causes catastrophic issues. I believe this is due to it using Microsoft JVM for its java processing, which happens to be unsupported now. This does not occur in XP from what ive seen
The web browser control uses the same shell as the installed version of Internet Explorer, but in my experience, the full browser handles things more gracefully.
It is worth adding some debug to the JavaScript to see where the problem is - is it because longtail isn't registering as loaded, so no events are binding or is it because of a problem with the events.