Le contrôle WebBrowser IE9 supportera-t-il toutes les fonctionnalités d'IE9, y compris SVG?
Je suis récemment passé à IE9-beta. Maintenant, dans mon application WinForm .Net (3.5), je souhaite utiliser le contrôle WebBrowser.
Ma question est donc de savoir si le contrôle WebBrowser présentera toutes les propriétés et fonctions de IE9?
Mon souci est, je veux rendre certains graphiques SVG sur elle.
La "version" IE9 du contrôle WebBrowser, à l'instar de la version IE8, regroupe en réalité plusieurs navigateurs en un. Contrairement à la version IE8, vous avez un peu plus de contrôle sur le mode de rendu dans la page en modifiant le doctype. Bien sûr, pour changer le mode du navigateur, vous devez définir votre registre de la même manière que la réponse précédente. Voici un fragment de fichier reg pour FEATURE_BROWSER_EMULATION:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"contoso.exe"=dword:00002328
Voici le jeu complet de codes:
- 9999 (0x270F) - Internet Explorer 9. Les pages Web sont affichées en mode Norme IE9, quelle que soit la directive! DOCTYPE.
- 9000 (0x2328) - Internet Explorer 9. Les pages Web contenant des directives! DOCTYPE basées sur des normes sont affichées en mode IE9.
- 8888 (0x22B8) -Les pages Web sont affichées en mode Norme IE8, quelle que soit la directive! DOCTYPE.
- 8000 (0x1F40) - Les pages Web contenant des directives DOCTYPE basées sur des normes sont affichées en mode IE8.
- 7000 (0x1B58) - Les pages Web contenant des directives DOCTYPE basées sur des normes sont affichées en mode IE7 Normes.
La documentation complète:
http://msdn.Microsoft.com/en-us/library/ee330730%28VS.85%29.aspx#browser_emulation
Le contrôle WebBrowser utilisera la version de IE que vous avez installée, mais pour des raisons de compatibilité, il affichera les pages en mode standard IE7 par défaut.
Si vous souhaitez tirer parti des nouvelles fonctionnalités d'IE9, vous devez ajouter la balise META <meta http-equiv="X-UA-Compatible" content="IE=9" > à l'intérieur de <head> balise de votre page HTML.
Cette balise META doit être ajoutée avant tout lien vers des fichiers CSS, JavaScript, etc., qui figurent également dans votre fichier <head> pour fonctionner correctement (seulement les autres <meta> tags ou le <title> tag peut venir avant).
Une alternative consiste à ajouter une entrée de registre à:
HKLM> LOGICIEL> Microsoft> Internet Explorer> Principal> FeatureControl> FEATURE_BROWSER_EMULATION
Et là, ajoutez 'myApplicationName.exe' avec la valeur '9000' pour forcer le contrôle WebBrowser à afficher les pages en mode IE9. Bien qu'il y ait d'autres valeurs que vous pouvez aussi utiliser , notez également que ces documents ne sont pas tout à fait exacts, car il ne semble pas possible d'obtenir le rendu d'une page IE 8 mode quelle que soit la valeur que vous utilisez.
L'ajout de la clé de registre dans le même chemin dans HKCU au lieu de HKLM fonctionnera également. Cela est utile, car l'écriture sur HKLM nécessite des privilèges d'administrateur, contrairement à HKCU.
Dieu merci, j'ai trouvé ça. Ce qui suit est extrêmement important:
<meta http-equiv="X-UA-Compatible" content="IE=9" >
Sans cela, aucun des rapports que j'avais générés ne fonctionnerait après l'installation d'IE9, alors qu'il fonctionnait parfaitement dans IE8. Ils apparaîtront correctement dans un contrôle de navigateur Web, mais il y aurait des lettres manquantes, des espaces non encombrés, etc., lorsque j'ai appelé .Print (). C'étaient juste du HTML de base qui devrait pouvoir être rendu même en mosaïque. heh Je ne sais pas pourquoi le mode de compatibilité IE7 allait mal tourner. Notamment, vous pouvez .Print () la même page 5 fois et lui faire perdre des lettres différentes à chaque fois. Il serait même transféré dans la sortie PDF), donc c'est définitivement le navigateur.
Une note à propos de Windows 64 bits qui semble faire trébucher quelques personnes. Si votre application fonctionne sous Windows 64 bits, vous devrez probablement définir DWORD sous [HKLM\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION].
Juste pour être complet ...
Pour les systèmes d'exploitation 32 bits, vous devez ajouter une entrée de registre à:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
*******OU*******
Pour le système d'exploitation 64 bits, vous devez ajouter une entrée de registre à:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
Cette entrée doit être un DWORD, le nom étant le nom de votre exécutable, hébergeant le contrôle Webbrowser; c'est à dire.:
myappname.exe (NE PAS UTILISER "Contoso.exe" comme dans la page Web MSDN ... c'est juste un nom d'espace réservé)
Puis donnez-lui une valeur DWORD, selon le tableau de:
http://msdn.Microsoft.com/en-us/library/ee330730 (v = vs.85) .aspx # browser_emulation
J'ai changé en 11001 décimal ou 0x2AF9 hex --- (IE 11 EMULATION) car ce n'est pas la valeur DEFAULT (si vous avez IE 11 installé - ou quelle que soit la version).
Cet article MSDN contient des notes sur plusieurs autres modifications du registre qui affectent le comportement du navigateur Web Internet Explorer.
Je sais que ce fil est ancien et qu'il existe déjà des réponses complètes.
Juste au cas où vous ne le sachiez pas:
<meta http-equiv="X-UA-Compatible" content="IE=Edge" >
Vous n’avez pas à coder en dur IE numéro de version comme
<meta http-equiv="X-UA-Compatible" content="IE=9" >
Je suis totalement d'accord avec la solution proposée, mais je pense qu'un éclaircissement est important, je pense, pourrait être nécessaire.
Pour chaque processus (lire aussi: vshost.exe, votreWinformApplication.exe.svchost ou le nom de votre application.exe) qui devra ajouter un DWORD avec la valeur fournie, dans mon cas, je laisse 9000 (en décimal) dans l'application nom et exécution en douceur et script sans erreur.
l'erreur la plus commune est de croire qu'il est nécessaire d'ajouter "contoso.exe" AS IS et de penser que tout fonctionne!
Je suis venu à cette solution et cela n'a pas fonctionné pour moi! Parce que j'utilisais 64bit, j'ai dû remplacer le registre:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION
Au lieu de celui dont tout le monde parle:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
Oui, le contrôle WebBrowser utilise la version de IE que vous avez installée. Cela signifie bien sûr que si vous exécutez votre application sur une machine avec IE 8, le = IE 9 fonctionnalités dont vous dépendez ne seront pas disponibles.
J'ai aimé le code (C #) ci-après qui définit les paramètres de registre de votre application. Je ne sais pas s'il le coupera après l'installation si des autorisations sont nécessaires. Pour moi, cela a résolu un problème avec WebSocket qui n'était pas disponible dans un contrôle WebBrowser dans WPF.
J'ai eu le même problème, et les réponses du registre ici ne fonctionnaient pas.
J'avais un contrôle de navigateur dans la nouvelle version de mon programme qui fonctionnait bien sur XP, a échoué sous Windows 7 (64 bits). L'ancienne version fonctionnait à la fois sur XP et Windows 7.
La page Web affichée dans le navigateur utilise un étrange plug-in pour afficher les anciennes cartes SVG (je pense que c'est un Java).
Il s'avère que le problème est lié à la protection DEP dans Windows 7.
Les anciennes versions de dotnet 2 ne définissaient pas le drapeau obligatoire DEP dans le fichier exe, mais à partir de dotnet 2, SP 1 ou plus) (oui, le comportement de compilation et donc le comportement à l’exécution de sur quelle machine vous avez compilé, Nice ...).
Il est documenté sur un blog MSDN NXCOMPAT et le compilateur C # . Pour citer: Cela va sans aucun doute surprendre quelques développeurs ... téléchargez un service pack Framework, recompilez, exécutez votre application et vous obtenez maintenant des exceptions IP_ON_HEAP.
L'ajout de ce qui suit à la post-génération dans Visual Studio désactive DEP pour l'exe et tout fonctionne comme prévu:
all "$(DevEnvDir)..\tools\vsvars32.bat"
editbin.exe /NXCOMPAT:NO "$(TargetPath)"
- documentation Editbin
- Poubelle
/headersaffichera le réglage DEP sur un fichier .exe.