[résolu]problème pour importer un élément vb

Bonsoir,

Pour pouvoir utiliser une fonction spéciale je doit importer un fichier .vb (visual basic)
voila le code que je doit mettre quand je suis dans visual studio:

Code:

Imports MyApplication.libZPlay

ces lignes doivent êtres placées avant le code des class, des fenetres...
le problème: dans software zator on ne peut importer que des dll et nom des projets vb, peut on les importer? comment?

Merci de vos réponses

Bonjour,

En .Net, si on fait :

Code:

Imports System.Windows.Forms
[...]
Dim Frm As New Form()

Ca revient à faire directement :

Code:

[...]
Dim Frm As New System.Windows.Forms.Form()

En fait on peut dire que le Import allège un peu le code. En outre, il vous suffit "MyApplication.libZPlay." devant tout les nom de types membre de cet espace nom afin que l'on soit dispensé du Import, et ça fonctionnera

bonjour,

oké! je pensais que le import était obligatoire pour que sa fonctionne
sinon (pour éviter d'avoir encore à créer un post, je dois en être à mon 100ème ) je n'ai pas compris le principe du code dom dans le sdk de SZ2012, dans les plugins de sz2011 on créait un fichier xml qui contenait par exemple:

Code:


{PARAM1} = {PARAM2}.ToSting


alors qu'avec le code dom il faut renvoyer les paramètres dans différentes fonction; j'ai beau consulter la documentation du site de microsoft je ne comprend pas du tout comment sa fonctionne, pourriez vous svp m'expliquer un peu comment sa marche?

merci (et désolé de poster des messages tout les 2 jours )

Bonjour,

Aller, un petit tutoriel s'impose :

Qu'est-ce que CodeDom?
Ce sont des classes du .Net Framework qui permettent de générer du code VB.Net, C# et (anciennement) J#.

Quel est l'intérêt?
C'est d'abord plus rapide à générer que du simple texte (je sais, au premier point de vue ça semble illogique mais jugez par les performances entres SZ 2011 et 2012, elles sont bien meilleurs). C'est également assez souple, on peut générer tout type de code .Net, des classes complètes. Pour vous donner une idée, les codes générés pour les fenêtres sont entièrement écrit par une valeur CodeDom, et encore une fois, c'est plus rapide qu'avec un simple texte. L'intérêt est également de pouvoir lire facilement le code sans avoir besoin de créer son propre système de lecture et d'analyse du code, souvent pas très stable (même pour moi). On retrouve cet avantage dans la fonction permettant de passer du code VB.Net aux paramètres de l'action.

Comment on l'utilise?
Il faut dans un premier temps créer une valeur CodeDom :

Code:

Dim MonCodeDom As New System.CodeDom.AssignStatement(New System.CodeDom.CodeVariableReferenceExpression("Variable1"), New System.CodeDom.CodeVariableReferenceExpression("Variable2"))

Le code ci-dessus permettra de générer le code suivant :

Code:

Variable1 = Variable2

"AssignStatement" définie une assignation, et "CodeVariableReferenceExpression" définie une référence à une variable. Il y a plein d'autre fonctions, elle permet de faire référence à des méthodes, fonctions, types, conditions, boucles, assignation, déclaration de variables, de méthodes...etc
Seulement voila, comment on passe de la valeur CodeDom à du code VB.Net ou C# généré? Il suffit d'utiliser une fonction dans .Net qui va traduire la valeur en code :

Code:

Dim sourceWriter As New IO.StringWriter()
CodeDom.Compiler.CodeDomProvider.CreateProvider("VB").GenerateCodeFromStatement(MonCodeDom, sourceWriter, New CodeDom.Compiler.CodeGeneratorOptions())
sourceWriter.Close()
MsgBox("Le code généré est : " & sourceWriter.ToString())

Le code ci-dessus génère le code VB.Net (grâce à la partie CreateProvider("VB") du code. Si vous voulez du C#, mettez C à la place de VB) en fonction de la valeur CodeDom contenu dans la variable MonCodeDom.
Note : dans SZ, on doit générer le code VB.Net pour l'afficher dans la fenêtre des paramètres d'un action. En revanche on renvoie la valeur CodeDom brut à SZ pour la génération, et SZ s'occupera de générer tous les codes d'un coup, car, pendant la génération, il assemble un énorme bloc de CodeDom (qui forme votre projet) avant de le compiler (la génération est plus rapide que sous SZ 2011, vous l'aurez sûrement remarqué).

Et si je n'arrive vraiment pas à utiliser CodeDom?
Pas de panique : on peut toujours utiliser du texte. Il suffit de retourner une valeur comme celle-ci :

Code:

New System.CodeDom.CodeSnippetExpression("Variable1 = Variable2")

Dans ce cas, pour les fenêtre des paramètres de l'action, vous pouvez très bien travailler uniquement avec du texte. Mais pour la fonction GetVBCode de votre action, il faudra retourner une valeur CodeDom (tel que celle ci-dessus si vous ne voulez pas tout générer avec CodeDom).

Au final, utiliser CodeDom est un bénéfice en performance. Évidemment, sur une seule action, on ne voit pas de différence, mais quand on a des projets avec 300 actions, on s’aperçoit que c'est bien plus rapide qu'avec du simple texte (je compare encore à SZ 2011 à ce moment là).

En espérant vous avoir éclairci un peu

[EDIT]
Voici un petit tutoriel sur CodeDom, en C#. Mais pas de panique, c'est pareil en VB.Net, il y a juste la syntaxe qui change :
http://vincentlaine.developpez.com/tuto/dotnet/codedom/

Bonsoir,

Non non, ça supporte le multi ligne (en tout cas pour les "CodeSnippetExpression" et "CodeSnippetStatement", je n'ai pas testé pour les autres).
Juste, petite correction, c'est :

Code:

New System.CodeDom.CodeSnippetExpres​sion("If Variable1 <> Variable2 Then" & System.Environment.NewLine & "MsgBox(" & Chrw(34) & "Les valeurs sont inégalle" & Chrw(34) & ")" & System.Environment.NewLine & "End if")

Et si on ne veut tout écrire sur une seule ligne :

Code:

New System.CodeDom.CodeSnippetExpres​sion("If Variable1 <> Variable2 Then MsgBox(" & Chrw(34) & "Les valeurs sont inégalle" & Chrw(34) & ") : Variable1 = Variable2 : Variable3 = Variable4"

rebonjour à tous,

@Admin: merci pour le tutoriel, je ne m'endormirai pas énervé ce soir ^^
donc il n'y aura pas un problème de performance ou autre si je renvoie juste la valeur retournée comme ceci:

Code:

New System.CodeDom.CodeSnippetExpression("Variable1 = Variable2")


merci

Bonjour,

En fait si, je vous explique :
Ce qui est long à s'exécuter, c'est ce genre de code :

Code:

Me.Param1 & " = " & Me.Param2

Bon, évidemment, sur un code aussi petit, on ne voit pas vraiment de différence. Mais plaçons ce code dans le contexte d'une action : l'utilisateur a sélectionné une variable "Variable1", enregistré dans Param1, et une variable "Variable2", enregistré dans le paramètre Param2 de votre action.

On veut obtenir au final le code suivant :

Code:

Variable1 = Variable2

Pour générer le code ci-dessus avec CodeDom, vous avez donc deux solutions.

La première, la plus simple, mais la moins performante :

Code:

New System.CodeDom.CodeSnippetExpression(Me.Param1 & " = " & Me.Param2)

Le seconde, plus compliqué à votre niveau, mais plus propre et plus rapide d'exécution :

Code:

New System.CodeDom.AssignStatement(New
System.CodeDom.CodeVariableReferenceExpression(Me.Param1), New
System.CodeDom.CodeVariableReferenceExpression(Me.Param2))

Le code généré sera donc le même, mais une méthode sera exécuté plus rapidement que d'autre.

Vous verrez que plus vous utiliserez CodeDom (en passant le moins possible par les SnippetExpression et SnippetStatement), plus ça vous semblera simple, et ça deviendra un automatisme. En 2 ans, j'ai codé 340 actions avec du CodeDom dedans, ça n'a plus de secret pour moi depuis longtemps . Au bout de 4 ou 5 actions, plus soucis, en plus, c'est toujours le même principe, et en général je copiais le CodeDom d'une action, et je changeais juste quelques petits paramètres dedans pour l'adapter, et voila, terminé.
Ma première action, j'ai du la faire "bien" en 2 ou 3 heures. Maintenant, en comptant la documentation sur l'action et les testes, il me faut environ 30min pour faire 1 action. Des fois 5 à 10 minutes suffises, en copiant des actions existantes et en renommant juste les fichiers et en changeant juste quelques paramètres dedans. Ca a été le cas pour les actions "Obtenir le titre du projet", "Obtenir le copyright du projet"...etc : j'ai fait une action, je l'ai copié, renommé les fichiers, changé les noms des classes, changé le nom de l'action, sa description, l'icône, UN seul paramètre dans le CodeDom, , changé la documentation, et voila, terminé, tout ça en 5 minutes environ

Bonne journée

re,

en effet pour 340 actions tu (tutoyage si vous permettez) avait tout intéret à trouver une manière plus rapide
maintenant que j'ai enfin compris je vais pouvoir faire des beau plugins

Re-bonjour,

Génial SZ 2012 pose la base des prochaines versions de ce logiciel, les actions auront désormais toutes cette architecture à laquelle viendra s'accrocher des nouveautés c'est pourquoi, en toute honnêteté, je conseil de passer à la version 2012, qui est déja plus stable et performante que la version 2011.

[EDIT]
Bientôt viendra de la documentation complémentaire sur les Plugins, notamment sur les fonctions délivrés par la propriété Tools, qui permet par exemple de récupérer la liste des variables la liste des contrôles, le titre du projet...etc

[EDIT]
Bientôt viendra de la documentation complémentaire sur les Plugins, notamment sur les fonctions délivrés par la propriété Tools, qui permet par exemple de récupérer la liste des variables la liste des contrôles, le titre du projet...etc

et se sera pour la version finale?

Bonjour,

Ou la prochaine bêta, je ne sais pas encore.

Bonjour,

Oui, et je ferais tout mon possible pour que les projets soient compatible avec la prochaine version. A ce stade je peux rien garantir (j'ai rien commencé), mais comme tout le monde s'en plaint, je vais au moins essayer

Bonjour,

Techniquement, oui, les fichier szproj sont fait pareil et donc compatible. Les fenêtres, elles, sont faites avec CodeDom depuis SoftwareZator 1.0. Le problème de compatibilité vient de l'éditeur de fonctions et des actions :
- Dans SoftwareZator 1.0, les fonctions sont enregistrés au format XML et les fenêtres (CodeDom) sont sérialisés dans deux fichiers différents.
- Dans SoftwareZator 2011, les fenêtres (CodeDom) et fonctions sont stockés dans le même fichier. Les fonctions ne sont plus au format XML mais sont directement sérialisé
- Dans SoftwareZator 2012, les fenêtres (CodeDom) et fonctions sont stockés dans le même fichier. Les fonctions sont cette fois-ci au format XAML (destiné au WPF et Workflow) et sérialisés dans le fichier, afin de tout stocké dans ce même fichier.
- Entre SoftwareZator 1.0 et 2011, les actions 1.0 sont compatibles avec les actions 2.0, car il y avait peu de différences (d'ailleurs, le FTP de SZ 2011 n'est autre que le plugin de SZ 1.0, qui a donc été entièrement refait pour la dernière bêta de SoftwareZator 2012 sortie dimanche).
- Entre SoftwareZator 1.0 et 2011, si les projets étaient incompatibles entre eux, c'est à cause des actions : certes les actions 1.0 sont compatibles sous SZ 2011, seulement les actions de SZ 1.0 ont été refaites pour SZ 2011, et en conséquence, ce n'était plus les mêmes. Par conséquence, à part pour les actions FTP, si on importe un projet SZ 1.0 dans SZ 2011, celui-ci ne trouvera pas les actions adéquates.
- Entre SZ 2011 et 2012, l'éditeur de fonction a entièrement changé, et l'architecture aussi. Pour les mêmes raison que précédemment, les projets ne sont pas compatibles entre eux.

En revanche, comme dans les prochaines versions on conservera le Workflow et que les actions ne changeront que très peu (des détails seulement), il y a de fortes chances pour que ça soit compatible, quitte à faire un assistant de mise à niveau, mais ça devrait fonctionner (si je ne fais pas de gros changements, mais bon, jusqu'ici, c'est pas prévu).