Discussion :

[Gaautman]

Bonjour,

Face au comportement plus qu'erratique des implémentations possible du WebBrowser de Microsoft dans Windev (que ce soit via l'activeX ou par un champ .net il y a des problèmes récurrents, aléatoires et d'une manière générale, insurmontables), je cherche a intégrer Chromium (moteur de Google Chrome) au sein de windev en tant que contrôle .Net, via l’excellente implantation proposée par Awesomium.

Awesomium propose principalement un contrôle WPF, mais aussi un contrôle WinForms. Bien que c’eut été la meilleure solution, je n'ai pas réussi a faire fonctionner la version WPF dans Windev. Pour ceux que ça intéresse, et parce que j'ai galéré comme un dingue pour trouver la solution, il est possible d'utiliser un contrôle WPF n'appartenant pas au namespace System.Windows.Controls dans un champ WPF malgré le fait que le champ ne permette pas d'accéder a la partie déclaration du XAML (complétement con). Exemple :

Normalement, lorsque l'on utilise un controle WPF qui a sont propre namespace (ici Awesomium.Windows.Controls, "instancié" par "awe:"), le XAML complet d'une fenetre ressemble a ça :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<Window
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:awe="clr-namespace:Awesomium.Windows.Controls;assembly=Awesomium.Windows.Controls">
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <awe:WebControl/>
    </Grid>
</Window>

En fait avec le champ XAML de windev, le XAML a cette forme la :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<Canvas 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Background="White" >
   ...
   Code XAML inséré dans l'éditeur ou via affectation dans le code
   ...
</Canvas>

Comme vous le voyez, la partie de déclaration des namespace est fixée en dur. Heureusement, le XAML permet de déclarer un namespace dans n'importe quel conteneur (c'est pas documenté mais ça marche). Du coup, si on déclare le namespace dans un conteneur grid dans le code d'initialisation du champ XAML, on peut utiliser le controle (il faut avoir importé les assembly .net) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
DOTNET_XAML = [
<Grid xmlns:awe="clr-namespace:Awesomium.Windows.Controls;assembly=Awesomium.Windows.Controls">
    <awe:WebControl>
</Grid>
]

Tout du moins, ça marche avec d'autres contrôles WPF, y compris les controles auxiliaires d'Awesomium (contextmenu, etc). Malheureusement, avec le WebControl qui est une instance du navigateur, je pense qu'il y a des appel a des fonctions trop bas niveau et j'obtiens systématiquement un beau crash de WDTst.exe. Peut être qu'il y a des dépendances qui m'échappent, mais je pense que c'est lié a une interférence avec le moteur graphique de windev qui hook pas mal (trop) de trucs. En tout cas ça dépasse de loin mes compétences. Si quelqu'un veut tenter le coup, je lui ai ouvert la voie.

En désespoir de cause, je me suis tourné vers la version winform d'Awesomium. Mes premiers tests sont très positifs : c'est stable, rapide, possibilité de gérer le drag and drop, les événements souris/clavier (avec quelques astuces, mais c'est faisable, contrairement au MS webbrowser), de manipuler le DOM, d'interagir dans les deux sens avec du javascript dans les pages web. C'était trop beau pour être vrai (comme toujours avec WinDev).

Le controle (WinForm ou WPF) d'Awesomium s'initialise avec des paramètres par défaut qu'il n'est plus possible de modifier une fois qu'il est initialisé (ce sont notamment tout les paramétrés lié au charset, a la langue, a la gestion ou non des scripts, du presse-papier, voir WebPreferences. Si je le place directement dans un champ WinForm, il est impossible de faire quoi que ce soit avant l'initialisation du contrôle, en tout cas, que ce soit dans le traitement d'initialisation du champ ou dans les déclarations globales de la fenêtre, on est déjà initialisé (windev a déjà appelé le "InitializeComponent()").

Je me suis donc dit que je pouvais créer mon contrôle à la volée, en définissant un conteneur "Panel" dans le champ Winform et en appelant la méthode "Add". Sous VS2012 en VB.NET, ça marche. Evidement, sous WinDev, ça pose problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
// Les preferences de la session :
gpclWebPreferences est une WebPreferences dynamique = allouer une WebPreferences(Vrai)
gpclWebPreferences.CanScriptsAccessClipboard = Vrai
// L'instance de session qui sera utilisée par Awesomium :
gpclWebSession est une WebSession dynamique
gpclWebSession = WebCore.CreateWebSession(gpclWebPreferences)
// Creation du controle :
gpclWebControl est un WebControl dynamique = allouer un WebControl
gpclWebControl.WebSession = gpclWebSession
// Ajout du controle au Panel (champ dotnet windev) :
DOTNET_WebControl.Controls.Add(gpclWebControl)

Et ben non, j'obtiens un beau "Erreur :Opérateur . interdit." sur "." du ".Add". La liste des méthodes de "Controls" est désespérément vide. En fouillant dans la liste des assemblages .net importés, je m'aperçois qu'effectivement, "System.Windows.Forms.Control.ControlCollection" (le membre "Controls" est de ce type) n'est pas listé. En fait, je m'aperçoit que toute classe ayant plus de 3 classes parentes est absente, avec toute ses méthodes.

A noter que taper la ligne suivante dans l'editeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gpclControlCollection est un ControlCollection

provoque un plantage immédiat de windev.

Quelqu'un a t'il déjà rencontré le problème ?

[Gaautman]

Bon, je m'auto-congratule et je vous fait part de la solution.

Après avoir bataillé en passant par des chemins dérivés en tout genre, j'en conclus que quand l'éditeur de code commence a refuser quelque chose qui vient d'un assembly .NET, c'est pas la peine d'essayer de passer par des chemins dérivés, ça marchera pas, ou alors ça fera semblant de marcher. Pour la petite histoire, je suis tombé sur un post qui parlait de l’accès au classes génériques, et qui recommandait de créer un assembly bidon utilisant les classes qui manquent, puis de l'importer dans le projet. Ça marche plus ou moins. Ca a marché pendant quelques heures, puis soudainement, je me suis mis a avoir tout un tas de comportements étranges (les evenements qui se déclenchent plus, ou aléatoirement), et puis suite a un énième plantage de l'environnement, ça m'a foiré le projet, impossible de l'ouvrir sans plantage.

Finalement, j'ai trouvé un moyen simple, efficace et radical : je me suis créé un petit assembly en VB.net avec des fonctions statiques qui sont des raccourcis pour les trucs qui passent mal sur windev. Exemple pour le .add sur ma controlCollection :

Code VB.NET :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Public Class WDHelpers
    Public Shared Sub AddControlToControlCollection(addedControl As Control, targetCollection As Control.ControlCollection)
        targetCollection.Add(addedControl)
    End Sub
End Class

Et du coup je suis en mesure d'annoncer que c'est possible, on peut utiliser Chromium dans une appli Windev. Par contre, contrairement a ce que je pensais, pas facile d’accéder au DOM depuis Windev, car ils utilisent du code .NET "dynamique" pour utiliser les instructions du javascript et les compiler "a la volée". Je doute que ce soit faisable dans Windev, c'est donc un point en faveur du webbrowser de MS. Reste qu'on peut quand même faire beaucoup de choses rien qu'avec les instructions ExecuteJavascript/ExecuteJavascriptWithResult, qui permettent d'executer du javascript dans la page et de récupérer la valeur des variables.

Reste a voir ce que ça donne en terme de stabilité, mais en terme de performances, c'est très largement au dessus du webbrowser sur les 2 PC sur lesquels j'ai essayé.

Pour ceux qui veulent essayer :
- Télécharger le SDK d'Awesomium et l'installer
- Importez dans votre projet les assembly "Awesomium.Core.dll", "Awesomium.Windows.Forms.dll" ainsi que "WDNetHelpers.dll", ma classe utilitaire : WDNetHelpers.zip (ou recréez la fonction ci-dessus dans l'assembly perso de votre choix)
- Créer une fenêtre avec un champ winform ("DOTNET_WebControl" pour moi) et placez y un System.Windows.Forms.Panel

Code d'initialisation de la fenetre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Les preferences de la session :
// Voir http://docs.awesomium.net/html/T_Awesomium_Core_WebPreferences.htm
gpclWebPreferences est WebPreferences dynamique = allouer WebPreferences(Vrai)
gpclWebPreferences.CanScriptsAccessClipboard = Vrai
// L'instance de session qui sera utilisée par Awesomium :
gpclWebSession est WebSession dynamique
gpclWebSession = WebCore.CreateWebSession(gpclWebPreferences)
// Creation du controle :
gpclWebControl est "Awesomium.Windows.Forms.WebControl" dynamique
gpclWebControl = allouer "Awesomium.Windows.Forms.WebControl"
gpclWebControl.WebSession = gpclWebSession
// Ajout du controle au Panel (champ dotnet windev) via méthode perso :
WDHelpers.AddControlToControlCollection(gpclWebControl,DOTNET_WebControl.Controls)
gpclWebControl.Dock = DockStyle.Fill
gpclWebControl.Focus()
// Override sur le menu contextuel :
gpclWebControl.add_ShowContextMenu(DotNetDélégué("NoContextMenu","Awesomium.Core.ShowContextMenuEventHandler"))
// On navigue sur ce forum !
gpclUri est Uri("http://www.developpez.net/forums/f226/environnements-developpement/windev/")
gpclWebControl.Source = gpclUri

La procédure NoContextMenu, si vous voulez virer le menu contextuel par défaut (sinon virer aussi le DotNetDélégué ci dessus):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
PROCEDURE NoContextMenu(src,args)
args:Handled = Vrai

Par contre il est impératif d'appeler manuellement le garbage collector sur le champ a la fermeture de la fenêtre (plantage garanti sinon) :
Code de fermeture de la fenetre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DOTNET_WebControl.Dispose()

A noter qu'il est parfaitement possible d'utiliser directement le contrôle Awesomium.Windows.Forms.WebControl dans un champ Winform et de pas avoir a faire tout ce bazar. Par contre, impossible de changer les WebPreferences par défaut dans ce cas. Pour gérer le Drop and Drop, ça a l'air de fonctionner de manière stable en utilisant ExplorerAccepte sur le champ + l'evenement WM_DROPFILE.

Pour l'info, je fais tout ça pour utiliser CKEditor (editeur HTMl Wysiwyg) dans windev en local, ce qui fonctionnait plus ou moins dans le webbrowser de microsoft et fonctionne beaucoup mieux avec Chromium. Seul regret, Awesomium n'a pas encore intégré le correcteur orthographique de Chromium, sous le webbrowser c'était possible d'avoir celui d'IE, a condition de bidouiller le registre et d’être sous windows 8.
Voila ce que ça donne :



C'est autre chose que le champ de saisie HTML !

[jurassic pork]

hello Gaautman,
je te congratule aussi pour ta solution, cela semble bien fonctionner. J'ai essayé aussi d'utiliser le controle WPF. Même punition que toi, un crash de WDtest avec de multiples fenêtres MIcrosoft visual c++ Runtime library Error qui s'ouvrent. J'avais essayé avec ce code :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
XAML2 = [
<UserControl
xmlns:awe="clr-namespace:Awesomium.Windows.Controls;assembly=Awesomium.Windows.Controls" 
xmlns:core="clr-namespace:Awesomium.Core;assembly=Awesomium.Core"
>
<UserControl.Resources>
<awe:WebSessionProvider x:Key="mySession">
<core:WebPreferences 
SmoothScrolling="True"
LoadImagesAutomatically="False"/>
</awe:WebSessionProvider>
</UserControl.Resources>
<StackPanel>
<awe:WebControl
Name="webControl" 
WebSession="{Binding Source={StaticResource mySession}}" 
Source="http://google.fr"
/>
</StackPanel>
</UserControl>
]

Comme tu l'indiquais le problème doit être complexe à régler et semble plutôt être du côté de windev.

Concernant le problème :

En fouillant dans la liste des assemblages .net importés, je m'aperçois qu'effectivement, "System.Windows.Forms.Control.ControlCollection" (le membre "Controls" est de ce type) n'est pas listé. En fait, je m'aperçoit que toute classe ayant plus de 3 classes parentes est absente, avec toute ses méthodes.

je crois que c'est plutôt ça le problème ( trouver dans la doc windev "utiliser des assemblages .net dans un projet)

Les membres de type "classe" des classes et/ou des collections sont visibles en .NET uniquement si la classe est elle aussi exportée.

je pense que la classe ControlCollection n'est pas exportée.

comme je n'ai pas vb.net mais c# j'ai traduit ton code pour pouvoir utiliser la fonction add de ControlCollection en c# et voilà ce que cela donne :

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
using System;
using System.Collections.Generic;
using System.Windows.Forms;
 
namespace MesClasses
{
	public class MyControlClass
	{
		public static void AddControlToControlCollection( Control addedControl ,
		                                             Control.ControlCollection targetCollection)
		{
			targetCollection.Add(addedControl);		
		}			
	}
 
 
}

cela crée un assemblage, que j'incorpore dans mon projet windev et j'appelle la fonction comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MyControlClass.AddControlToControlCollection(GpclWebControl,DOTNET_WebControl.Controls)

Ami calmant, J.P

[miamitsoa]

Bonjour,

Avant tout, merci pour ce travail fastidueux et tres interessant.

ENsuite, j'aurai voulu savoir s'il était possible de disposer d'un petit projet windev avec vos sources que l'on pourrai modifier après.

j'ai essaye de suivre tout ce que vous avez dit mais cela ne marche pas encore.

Je vous remercie d'avance

Andy

[andalex]

Wow. Bravo pour ce travail !
ça fait plaisir de voir des gens qui partagent leurs connaissances.

Comme mon collègue juste avant moi, pourriez vous nous mettre un projet WINDEV minimum permettant aux pauvres mortels comme nous de sortir al tête de l'eau ?

Reconnaissance éternelle.. !

PS : Je n'ai que Windev (17). Je n'ai pas la possibilité de faire quoi que ce soit en C#, VB.NET, etc

[andalex]

Controle_Chrome.zip

J'ai débuté il y a peu sous windev.
Je n'avais pas compris qu'on pouvait intégrer des champs Dot.NET winform (mes excuses).

J'ai donc respecté vos consignes et j'ai installé awesomium, puis, dans Description>Général (du champ DOTNET_WebControl), j'ai importé les 3 DLL (la troisième vient de votre archive) :
Awesomium.Core.dll
Awesomium.Windows.Forms.Design.dll
WDNetHelpers.dll

J'ai aussi fait le reste (ajout de procédure, etc).
Quand je teste le tout, j'ai une erreur :

Erreur :Opérateur . interdit.

ça vient de cette ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WDHelpers.AddControlToControlCollection(gpclWebControl,DOTNET_WebControl.Controls)

Pour l’événement de fermeture de la fenêtre, avec l'instruction liée au garbage collector, j'ai la même erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DOTNET_WebControl.Dispose()

Ma question est la suivante, savez-vous comment arranger ça ?
Je me doute que ça doit être une erreur de débutant.

J'ai mis mon projet en pièce-jointe (ça fera également plaisir au collègue qui a posté juste avant moi)

Ben à vous !

Ps : je crois que ça ferait plaisir à énormément de devs que l'on propose un projet minimal permettant d'initialiser une instance de Chromium.
Ps 2 : Je suis sous Windev 18

[andalex]

hello Gaautman,
je te congratule aussi pour ta solution, cela semble bien fonctionner. J'ai essayé aussi d'utiliser le controle WPF. Même punition que toi, un crash de WDtest avec de multiples fenêtres MIcrosoft visual c++ Runtime library Error qui s'ouvrent. J'avais essayé avec ce code :

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
XAML2 = [
<UserControl
xmlns:awe="clr-namespace:Awesomium.Windows.Controls;assembly=Awesomium.Windows.Controls" 
xmlns:core="clr-namespace:Awesomium.Core;assembly=Awesomium.Core"
>
<UserControl.Resources>
<awe:WebSessionProvider x:Key="mySession">
<core:WebPreferences 
SmoothScrolling="True"
LoadImagesAutomatically="False"/>
</awe:WebSessionProvider>
</UserControl.Resources>
<StackPanel>
<awe:WebControl
Name="webControl" 
WebSession="{Binding Source={StaticResource mySession}}" 
Source="http://google.fr"
/>
</StackPanel>
</UserControl>
]

Comme tu l'indiquais le problème doit être complexe à régler et semble plutôt être du côté de windev.

Concernant le problème :

je crois que c'est plutôt ça le problème ( trouver dans la doc windev "utiliser des assemblages .net dans un projet)

je pense que la classe ControlCollection n'est pas exportée.

comme je n'ai pas vb.net mais c# j'ai traduit ton code pour pouvoir utiliser la fonction add de ControlCollection en c# et voilà ce que cela donne :

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
using System;
using System.Collections.Generic;
using System.Windows.Forms;
 
namespace MesClasses
{
	public class MyControlClass
	{
		public static void AddControlToControlCollection( Control addedControl ,
		                                             Control.ControlCollection targetCollection)
		{
			targetCollection.Add(addedControl);		
		}			
	}
 
 
}

cela crée un assemblage, que j'incorpore dans mon projet windev et j'appelle la fonction comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MyControlClass.AddControlToControlCollection(GpclWebControl,DOTNET_WebControl.Controls)

Ami calmant, J.P

Salut !
Pour moi, c'est encore pire. Je n'ai ni vb.net ni c#.
Peux-tu m'envoyer la dll de ton import rédigé en c# ?
J'ai la même erreur que vous, les gars.

[andalex]

Bon il s'avère que j'avais oublié de placer System.Windows.Forms.Panel dans le composant .NET (Description>Classe .NET 2.0)

Autre problème : Quand je lance le test, j'ai une erreur :

Erreur à la ligne 13 du traitement Déclarations globales de FEN_Principale.
L'objet <WDHelpers> est inconnu dans l'assemblage <C:\Users\XXX\Desktop\WDNetHelpers.dll>.
Vérifier que la version de l'assemblage <C:\Users\XXX\Desktop\WDNetHelpers.dll> utilisée en exécution est la même que la version utilisée pour la compilation du projet.
L'objet de type <WDNetHelpers.WDHelpers> (assemblage <C:\Users\XXX\Desktop\WDNetHelpers.dll>) n'a pas pu être créé
L'assemblage <D:\Mes Projets\Controle_Chrome\Exe\WDNetHelpers.dll> n'a pas pu être ouvert
Le framework .NET a renvoyé l'erreur suivante :
Impossible de charger le fichier ou l'assembly 'file:///D:\Mes Projets\Controle_Chrome\Exe\WDNetHelpers.dll' ou une de ses dépendances. L'opération n'est pas prise en charge. (Exception de HRESULT : 0x80131515)
L'assemblage <WDNetHelpers> n'a pas pu être ouvert

----- Informations techniques -----

Projet : Controle_Chrome

Appel WL :
Traitement de 'Déclarations globales de FEN_Principale' (FEN_Principale), ligne 13, thread 0

Que s'est-il passé ?
L'objet <WDHelpers> est inconnu dans l'assemblage <C:\Users\XXX\Desktop\WDNetHelpers.dll>.
Vérifier que la version de l'assemblage <C:\Users\XXX\Desktop\WDNetHelpers.dll> utilisée en exécution est la même que la version utilisée pour la compilation du projet.
L'objet de type <WDNetHelpers.WDHelpers> (assemblage <C:\Users\XXX\Desktop\WDNetHelpers.dll>) n'a pas pu être créé
L'assemblage <D:\Mes Projets\Controle_Chrome\Exe\WDNetHelpers.dll> n'a pas pu être ouvert
Le framework .NET a renvoyé l'erreur suivante :
Impossible de charger le fichier ou l'assembly 'file:///D:\Mes Projets\Controle_Chrome\Exe\WDNetHelpers.dll' ou une de ses dépendances. L'opération n'est pas prise en charge. (Exception de HRESULT : 0x80131515)
L'assemblage <WDNetHelpers> n'a pas pu être ouvert

Code erreur : 200007
Niveau : erreur fatale (EL_FATAL)

Dump de l'erreur du module 'wd180net4.dll' (18.0.12.1).
Identifiant des informations détaillées (.err) : 200007
Informations de débogage :

Code x :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
System.IO.FileLoadException: Impossible de charger le fichier ou l'assembly 'file:///D:\Mes Projets\Controle_Chrome\Exe\WDNetHelpers.dll' ou une de ses dépendances. L'opération n'est pas prise en charge. (Exception de HRESULT : 0x80131515)
Nom de fichier*: 'file:///D:\Mes Projets\Controle_Chrome\Exe\WDNetHelpers.dll' ---> System.NotSupportedException: Tentative de chargement d'un assembly à partir d'un emplacement réseau qui aurait entraîné l'utilisation de l'assembly en mode Bac à sable (sandbox) dans les versions antérieures du .NET Framework. Cette version du .NET Framework n'activant pas la stratégie CAS par défaut, ce chargement peut être dangereux. Si ce chargement n'est pas destiné à utiliser l'assembly en mode Bac à sable (sandbox), activez le commutateur loadFromRemoteSources. Pour plus d'informations, consultez http://go.microsoft.com/fwlink/?LinkId=155569.
   à System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   à System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   à System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   à System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
   à System.Reflection.Assembly.LoadFrom(String assemblyFile)
   à CDotNetLoader.__pclLoadAssembly(CDotNetLoader* , Char* pszFileName, CXError* pclErreur)

Informations supplémentaires :
EIT_PILEWL :
Déclarations globales de FEN_Principale (FEN_Principale), ligne 13
EIT_DATEHEURE : 02/03/2015 17:00:40

----- Sous-erreur n°1 -----

Que s'est-il passé ?
L'assemblage <WDNetHelpers> n'a pas pu être ouvert

Code erreur : 200003
Niveau : erreur fatale (EL_FATAL)

Dump de l'erreur du module 'wd180net4.dll' (18.0.12.1).
Identifiant des informations détaillées (.err) : 200003


----- Sous-erreur n°2 -----

Que s'est-il passé ?
L'assemblage <C:\Users\XXX\Desktop\WDNetHelpers.dll> n'a pas pu être ouvert
Le framework .NET a renvoyé l'erreur suivante :
Impossible de charger le fichier ou l'assembly 'file:///C:\Users\XXX\Desktop\WDNetHelpers.dll' ou une de ses dépendances. L'opération n'est pas prise en charge. (Exception de HRESULT : 0x80131515)

Code erreur : 200007
Niveau : erreur fatale (EL_FATAL)

Dump de l'erreur du module 'wd180net4.dll' (18.0.12.1).
Identifiant des informations détaillées (.err) : 200007
Informations de débogage :

Code x :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
System.IO.FileLoadException: Impossible de charger le fichier ou l'assembly 'file:///C:\Users\XXX\Desktop\WDNetHelpers.dll' ou une de ses dépendances. L'opération n'est pas prise en charge. (Exception de HRESULT : 0x80131515)
Nom de fichier*: 'file:///C:\Users\XXX\Desktop\WDNetHelpers.dll' ---> System.NotSupportedException: Tentative de chargement d'un assembly à partir d'un emplacement réseau qui aurait entraîné l'utilisation de l'assembly en mode Bac à sable (sandbox) dans les versions antérieures du .NET Framework. Cette version du .NET Framework n'activant pas la stratégie CAS par défaut, ce chargement peut être dangereux. Si ce chargement n'est pas destiné à utiliser l'assembly en mode Bac à sable (sandbox), activez le commutateur loadFromRemoteSources. Pour plus d'informations, consultez http://go.microsoft.com/fwlink/?LinkId=155569.
   à System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   à System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   à System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   à System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
   à System.Reflection.Assembly.LoadFrom(String assemblyFile)
   à CDotNetLoader.__pclLoadAssemblyWithFullPath(CDotNetLoader* , Char* pszFileName, CXError* pclErreur)

----- Sous-erreur n°3 -----

Que s'est-il passé ?
L'assemblage <WDNetHelpers> n'a pas pu être ouvert

Code erreur : 200003
Niveau : erreur fatale (EL_FATAL)

Dump de l'erreur du module 'wd180net4.dll' (18.0.12.1).
Identifiant des informations détaillées (.err) : 200003

J'ai pourtant bien importé les DLL.. Je sèche, là.

[Gaautman]

@Andalys :
De ce que tu décris, je pense que tu as oublié de déclarer ton champ .net comme étant un System.Windows.Forms.Panel (dans l'onglet "général" de la description du champ). Je ne sais plus si les champs .net de base sont proposés par défaut, si ce n'est pas le cas, il faut importer l'assemblage Windows.Forms dans le projet, en plus des autres.

Désolé pour ceux qui voudraient un projet exemple mais je n'ai plus windev sous la main (je faisais ça de passage dans une boite qui avait un applicatif développé en interne). Ceci étant, je suis pas allé beaucoup plus loin que ce que je donne dans les premiers posts. A noter aussi que à l'usage, j'ai eu des problèmes de fuite de mémoire, un problème récurrent sur la version .net d'awesomium si on en crois les posts sur leur forum / support. J'ai aussi eu des soucis lors de la récupération de variables et d’exécution javascript, mais apparemment la dernière version .NET (1.7.5) à une nouvelle API javascript qui doit résoudre tout ça. Tout ça pour dire que c'est quand même une solution "usine a gaz" et que je reste prudent sur la fiabilité en cas d'utilisation un tant soit peu intensive.

Dans mon cas, il s'agissait de fournir une textbox html un peu plus évolué que le champ RTF, je m'en sert pour faire tourner CKEditor, levelup dans l'usine a gaz : développement javascript dans un chromium dans un wrapper C++ dans un wrapper .Net dans une appli Windev qui n'est rien d'autre qu'un wrapper .Net/win32 . J'ai fini par le faire dans un exe séparé de l'appli principale, d'une part pour fournir un éditeur "standalone" et d'autre part pour que les très probables bugs ne viennent pas impacter l'appli principale.

Edit, @Andalys :
Bon ben t'as trouvé tout seul. Pour ton erreur, bienvenue dans le monde merveilleux de windev + .Net. Essaye de fermer windev, rouvrir et recompiler ton projet. Si ça ne marche pas, supprime l'assemblage dans la liste et réimporte le. Attention aussi aux problèmes de droits, évite de déplacer ton projet et/ou les dll que tu importe (la on dirait que quand tu a simporté la dll, elle étant sur ton bureau et du coup, il la cherche sur le bureau)

[andalex]

Oui, tu avais raison. J'avais effectivement oublié de spécifier System.Windows.Forms.Panel dans le composant .NET (Description>Classe .NET 2.0).
Pour finir, après une courte enquête, il s'avère que ma dernière erreur (par rapport à la DLL) se fait oublier quand je compile le projet (vers un .exe incluant toutes les DLL).
Je crois que le fait que mon chef de projet ait installé Windev sur le disque D: est la cause du problème.

Je recommande donc aux nouveaux venus de prendre mon projet en pièce-jointe (un des messages précédents) comme base si vous voulez inclure chrome à une application Windev (cadeau !).


Ps : De mon côté, j'ai toujours à gérer ce problème lié à l'exécution de windev sur un autre disque que le C: (à moins que ça ne vienne d'autre chose - si je trouve, je reviendrais ici pour partager)

[andalex]

J'ai trouvé.
En fait, le problème venait du fait que le dll "WDNetHelpers.dll" avait été créé à partir d'un autre ordinateur (celui de Gaautman).
Pour ceux qui réutiliseront ce projet, pensez bien à faire un clic droit sur chaque DLL et à cliquer sur "Débloquer" avant d'appliquer.




Vous trouverez ci-dessous l'archive "controle_chrome_standard.zip" contenant le projet controle_chrome.
Le projet inclue déjà les 3 DLL dans le répertoire Exe.
Avec ça vous avez la base pour intégrer chrome à une application Windev !

Controle_Chrome_standard.zip

Bonne soirée à tous et merci encore à Gaautman et jurassic pork pour leur travail et leurs recherches.

Bien à vous,
Alexandre.

[andalex]

Je me demande par contre si je pourrai gérer les champs et les événements aussi facilement qu'avec l'ActiveX de I.E. (à la manière de l'exemple didacticiel " WD Pilotage de IE")

à voir !

[andalex]

Il y a une grosse demande sur les différents forums de développeurs Windev quant à l'intégration d'un navigateur récent autre que IE.
ça vaudrait le coup de produire de petits tutoriels permettant d'intégrer la solution à une application Windev.
Voici les sujets sur lesquels les tutoriels devraient porter (corrigez-moi si je me trompe) :

- Exploiter les événements navigateur Awesomium sous Windev (abonnement aux événement existants, création de nouveaux événements)
- Récupération d'informations provenant du DOM (valuers de champs, etc)
- Modification d'informations via le DOM (dans l'autre sens, donc)
- Actions en Windev sur la page (clic, submit, etc) - que ce soit en passant par javascript ou non.

Bref, la base de ce qu'il est déjà possible de faire avec l'exemple didactique "WD pilotage de IE".
Cet outil (Awesomium) est vraiment génial et je crois qu'il n'y a pas d'alternative pour éviter d'utiliser IE dans Windev tout en utilisant un navigateur récent.

Je repasserai ici pour contribuer à cette doc en partageant mes découvertes (explications, captures d'écran si besoin, extraits de code et surtout projets de base zippés et directement exploitables pour les plus pressés). La communauté Windev n'est pas assez nombreuse. Il faudrait qu'un maximum de gens de bonnes volonté mettent la main à la pâte dans ce domaine.

[Shanoir64]

Vous trouverez ci-dessous l'archive "controle_chrome_standard.zip" contenant le projet controle_chrome.
Le projet inclue déjà les 3 DLL dans le répertoire Exe.
Avec ça vous avez la base pour intégrer chrome à une application Windev !

Controle_Chrome_standard.zip

Bonjour,
J'ai tenté d'utiliser ce projet exemple, possédant Windev 20 (version 64bits), la migration du projet échoue au moment de la compilation.

Une raison particulière ?
Ce projet n'est pas compatible avec Windev 20, ou peut être ce n'est pas une version 64 bits ?

Bien à vous,
Thierry

[andalex]

Bonjour,
Le projet a été compilé avec Windev 18 (32 bits).
De Windev 18 à Windev 20, ça ne devrait pas poser de problème.
D'autre part, pour la re-compilation du projet 32 bits sur une machine en 64 bits, ça devrait passer.
Auriez-vous une message d'erreur précis ?

Est-ce au niveau de la migration du projet qu'il y a une problème ou plus tard, au moment de la compilation ?
N'hésitez pas à lire les commentaires précédents sur l'importation des DLL (que j'ai d'ailleurs mis dans le dossier "Exe", il me semble) dans le projet.
D'autre part, je suis parti du principe qu'il suffisait d'utiliser les DLL liés Awesomium sans forcément installer l'application Awesomium (à voir si je me trompe).

Bien à vous,
Alexandre.

[Shanoir64]

Merci pour cette réponse rapide.
Il semblerait que le problème vienne du fait que j'utilise la version 64bits de windev20 et non la version 32bits.
Dès que je peux je testerait en version 32bits pour confirmer cela...
Cordialement,
Thierry

PS : Le plantage en WD20 64bits a lieu au moment de la première compilation du projet, suite à la migration.
Windev crash tout simplement

[andalex]

En m'aidant de cette page : http://doc.pcsoft.fr/fr-FR/?2030063&...ication_64bits, j'ai créé une configuration 64bits pour le projet.
En compilant, j'ai eu la réponse à votre problème : les DLL importés ne sont pas compatibles (au moins les deux DLL venant du projet Awesomium).

Si vous voulez toujours travailler en 64 bits :
Il faudrait que vous téléchargiez et que vous installiez une version 64 bits de Awesomium (si elle est disponible) et que vous recherchiez ensuite les DLL installés sur votre ordinateur.
N'hésitez pas à relire nos échanges pour avoir les détails.
J'ai pu recréer le projet assez facilement et j'ai rapporté les difficultés que j'ai eues et les solutions associées.

Enfin, dès que vous avez un projet vide viable en 64 bits, n'oubliez pas de partager comme je l'ai fait, ça aidera d'autres personnes (et si ils avancent de leur côté, on en profitera tous ! ).

Bien à vous,
Alexandre.

[andalex]

Bon, je m'auto-congratule et je vous fait part de la solution.

Après avoir bataillé en passant par des chemins dérivés en tout genre, j'en conclus que quand l'éditeur de code commence a refuser quelque chose qui vient d'un assembly .NET, c'est pas la peine d'essayer de passer par des chemins dérivés, ça marchera pas, ou alors ça fera semblant de marcher. Pour la petite histoire, je suis tombé sur un post qui parlait de l’accès au classes génériques, et qui recommandait de créer un assembly bidon utilisant les classes qui manquent, puis de l'importer dans le projet. Ça marche plus ou moins. Ca a marché pendant quelques heures, puis soudainement, je me suis mis a avoir tout un tas de comportements étranges (les evenements qui se déclenchent plus, ou aléatoirement), et puis suite a un énième plantage de l'environnement, ça m'a foiré le projet, impossible de l'ouvrir sans plantage.

Finalement, j'ai trouvé un moyen simple, efficace et radical : je me suis créé un petit assembly en VB.net avec des fonctions statiques qui sont des raccourcis pour les trucs qui passent mal sur windev. Exemple pour le .add sur ma controlCollection :

Code VB.NET :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Public Class WDHelpers
    Public Shared Sub AddControlToControlCollection(addedControl As Control, targetCollection As Control.ControlCollection)
        targetCollection.Add(addedControl)
    End Sub
End Class

Et du coup je suis en mesure d'annoncer que c'est possible, on peut utiliser Chromium dans une appli Windev. Par contre, contrairement a ce que je pensais, pas facile d’accéder au DOM depuis Windev, car ils utilisent du code .NET "dynamique" pour utiliser les instructions du javascript et les compiler "a la volée". Je doute que ce soit faisable dans Windev, c'est donc un point en faveur du webbrowser de MS. Reste qu'on peut quand même faire beaucoup de choses rien qu'avec les instructions ExecuteJavascript/ExecuteJavascriptWithResult, qui permettent d'executer du javascript dans la page et de récupérer la valeur des variables.

Reste a voir ce que ça donne en terme de stabilité, mais en terme de performances, c'est très largement au dessus du webbrowser sur les 2 PC sur lesquels j'ai essayé.

Pour ceux qui veulent essayer :
- Télécharger le SDK d'Awesomium et l'installer
- Importez dans votre projet les assembly "Awesomium.Core.dll", "Awesomium.Windows.Forms.dll" ainsi que "WDNetHelpers.dll", ma classe utilitaire : WDNetHelpers.zip (ou recréez la fonction ci-dessus dans l'assembly perso de votre choix)
- Créer une fenêtre avec un champ winform ("DOTNET_WebControl" pour moi) et placez y un System.Windows.Forms.Panel

Code d'initialisation de la fenetre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// Les preferences de la session :
// Voir http://docs.awesomium.net/html/T_Awesomium_Core_WebPreferences.htm
gpclWebPreferences est WebPreferences dynamique = allouer WebPreferences(Vrai)
gpclWebPreferences.CanScriptsAccessClipboard = Vrai
// L'instance de session qui sera utilisée par Awesomium :
gpclWebSession est WebSession dynamique
gpclWebSession = WebCore.CreateWebSession(gpclWebPreferences)
// Creation du controle :
gpclWebControl est "Awesomium.Windows.Forms.WebControl" dynamique
gpclWebControl = allouer "Awesomium.Windows.Forms.WebControl"
gpclWebControl.WebSession = gpclWebSession
// Ajout du controle au Panel (champ dotnet windev) via méthode perso :
WDHelpers.AddControlToControlCollection(gpclWebControl,DOTNET_WebControl.Controls)
gpclWebControl.Dock = DockStyle.Fill
gpclWebControl.Focus()
// Override sur le menu contextuel :
gpclWebControl.add_ShowContextMenu(DotNetDélégué("NoContextMenu","Awesomium.Core.ShowContextMenuEventHandler"))
// On navigue sur ce forum !
gpclUri est Uri("http://www.developpez.net/forums/f226/environnements-developpement/windev/")
gpclWebControl.Source = gpclUri

La procédure NoContextMenu, si vous voulez virer le menu contextuel par défaut (sinon virer aussi le DotNetDélégué ci dessus):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
PROCEDURE NoContextMenu(src,args)
args:Handled = Vrai

Par contre il est impératif d'appeler manuellement le garbage collector sur le champ a la fermeture de la fenêtre (plantage garanti sinon) :
Code de fermeture de la fenetre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DOTNET_WebControl.Dispose()

A noter qu'il est parfaitement possible d'utiliser directement le contrôle Awesomium.Windows.Forms.WebControl dans un champ Winform et de pas avoir a faire tout ce bazar. Par contre, impossible de changer les WebPreferences par défaut dans ce cas. Pour gérer le Drop and Drop, ça a l'air de fonctionner de manière stable en utilisant ExplorerAccepte sur le champ + l'evenement WM_DROPFILE.

Pour l'info, je fais tout ça pour utiliser CKEditor (editeur HTMl Wysiwyg) dans windev en local, ce qui fonctionnait plus ou moins dans le webbrowser de microsoft et fonctionne beaucoup mieux avec Chromium. Seul regret, Awesomium n'a pas encore intégré le correcteur orthographique de Chromium, sous le webbrowser c'était possible d'avoir celui d'IE, a condition de bidouiller le registre et d’être sous windows 8.
Voila ce que ça donne :



C'est autre chose que le champ de saisie HTML !

Salut !
Question : Quand je fais un ExecuteJavascriptWithResult, et que je récupère la réponse sous forme de chaîne (sous windev) de caractère :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
resultatRequete est une chaîne
resultatRequete= gpclWebControl.ExecuteJavascriptWithResult("uneFonctionRetournantTrue();")
Info(resultatRequete)

=> J'ai une erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Un élément de type 'objet .NET' ne peut pas être converti vers le type 'chaîne ANSI'

Trace complète :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Erreur à la ligne 2 du traitement Clic sur BTN_Recup_Info.
Un élément de type 'objet .NET' ne peut pas être converti vers le type 'chaîne ANSI'.
 
----- Informations techniques -----
 
Projet : Controle_Chrome
 
Appel WL :
Traitement de 'Clic sur BTN_Recup_Info' (FEN_Principale.BTN_Recup_Info), ligne 2, thread 0
 
Que s'est-il passé ?
Un élément de type 'objet .NET' ne peut pas être converti vers le type 'chaîne ANSI'.
 
Code erreur : 1021
Niveau : erreur fatale (EL_FATAL)
 
Dump de l'erreur du module 'wd180vm.dll' (18.0.150.7).
Identifiant des informations détaillées (.err) : 1021
Informations de débogage :
UEL = 69
Informations supplémentaires :
EIT_PILEWL :
Clic sur BTN_Recup_Info (FEN_Principale.BTN_Recup_Info), ligne 2
EIT_DATEHEURE : 12/03/2015 11:45:48

Quelqu'un a une idée ?

[jurassic pork]

hello,
le problème c'est que ExecuteJavascriptWithResult renvoie un objet .Net de type JSValue qui ressemble à un variant ( voir ici

tu peux essayer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
resultatRequete est un JSValue dynamique = gpclWebControl.ExecuteJavascriptWithResult("uneFonctionRetournantTrue();")
trace(resultatRequete.ToString())

Ou alors tenter ta chance avec un variant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

resultatRequete est un variant = gpclWebControl.ExecuteJavascriptWithResult("uneFonctionRetournantTrue();")

Ami calmant, J.P

[andalex]

Merci beaucoup, je vais tester ça !