La source de Dynamo est hébergée sur Github pour que tout le monde puisse la cloner et y apporter sa contribution. Dans ce chapitre, nous verrons comment cloner le dépôt à l’aide de git, compiler les fichiers sources avec Visual Studio, exécuter et déboguer une génération locale, et extraire toutes les nouvelles modifications de Github.

Localiser les dépôts Dynamo sur Github

Github est un service d’hébergement basé sur git, un système de contrôle de version permettant de suivre les modifications et de coordonner le travail entre les personnes. Git est un outil que nous pouvons utiliser pour télécharger les fichiers sources de Dynamo, et les maintenir à jour avec quelques commandes. L’utilisation de cette méthode permet d’éviter le travail fastidieux et inutile consistant à télécharger et à remplacer manuellement les fichiers sources à chaque mise à jour. Le système de contrôle de version git suit toutes les différences entre un dépôt de code local et un dépôt de code distant.

La source de Dynamo est hébergée sur Github DynamoDS dans ce dépôt : https://github.com/DynamoDS/Dynamo

Les fichiers source de Dynamo.

1. Cloner ou télécharger l’intégralité du dépôt

2. Afficher d’autres dépôts DynamoDS

3. Fichiers source de Dynamo

4. Fichiers spécifiques à Git

Tirer le dépôt Dynamo à l’aide de git

Avant de pouvoir cloner le dépôt, nous devons installer git. Suivez ce petit guide pour connaître les étapes de l’installation, et savoir comment configurer un nom d’utilisateur et une adresse email gihub. Pour cet exemple, nous utiliserons git en ligne de commande. Ce guide part du principe que vous utilisez Windows, mais vous pouvez également utiliser git sur mac ou linux pour cloner la source de dynamo.

Nous avons besoin d’une URL pour le dépôt Dynamo à cloner. Celle-ci se trouve en cliquant sur le bouton « Cloner ou télécharger » sur la page du dépôt. Copiez l’URL pour la coller dans l’invite de commande.

1. Sélectionnez « Cloner ou télécharger »

2. Copiez l’URL

Une fois git installé, nous pouvons cloner le dépôt Dynamo. Commencez par ouvrir l’invite de commande. Utilisez ensuite la commande de changement de répertoire cd pour naviguer jusqu’au dossier dans lequel les fichiers sources doivent être clonés. Dans ce cas, nous avons créé un dossier appelé Github dans Documents.

cd C:\Users\username\Documents\GitHub

Remplacez « username » par votre nom d’utilisateur

Dans l’étape suivante, nous allons lancer une commande git pour cloner le dépôt Dynamo à l’emplacement que nous avons spécifié. L’URL de la commande est obtenue en cliquant sur le bouton « Cloner ou télécharger » sur Github. Exécutez cette commande dans le terminal de commande. Notez que cela clonera la branche master du dépôt Dynamo qui est le code le plus à jour de Dynamo, et contiendra la dernière version du code de Dynamo. Cette branche change quotidiennement.

git clone https://github.com/DynamoDS/Dynamo.git

Nous savons que git fonctionne si l’opération de clonage s’est terminée avec succès. Dans l’explorateur de fichiers, naviguez jusqu’au répertoire où vous avez cloné pour voir les fichiers sources. La structure du répertoire doit être identique à la branche master du dépôt Dynamo sur Github.

1. Fichiers source de Dynamo

2. Fichiers Git

Générer le dépôt à l’aide de Visual Studio

Les fichiers sources étant maintenant clonés sur notre machine locale, nous pouvons générer un fichier exécutable pour Dynamo. Pour ce faire, nous devons configurer l’IDE Visual Studio et nous assurer que le .NET Framework et DirectX sont installés.

• Téléchargez et installez Microsoft Visual Studio Community 2015, un IDE (environnement de développement intégré) gratuit et complet (les versions ultérieures peuvent également fonctionner).

• Téléchargez et installez Microsoft .NET Framework 4.5 ou une version ultérieure.

• Installez Microsoft DirectX à partir du dépôt local Dynamo (Dynamo\tools\install\Extra\DirectX\DXSETUP.exe).

.NET et DirectX peuvent être déjà installés.

Une fois l’installation terminée, nous pouvons lancer Visual Studio et ouvrir la solution Dynamo.All.sln située dans Dynamo\src.

1. Sélectionnez File > Open > Project/Solution

2. Naviguez jusqu’au dépôt Dynamo et ouvrez le dossier src

3. Sélectionnez le fichier solution Dynamo.All.sln

4. Sélectionnez Open

Avant de pouvoir générer la solution, vous devez spécifier quelques paramètres. Nous devrions d’abord générer une version de débogage de Dynamo afin que Visual Studio puisse recueillir plus d’informations pendant le débogage pour nous aider à développer, et nous voulons cibler AnyCPU.

Ils deviendront des dossiers dans le dossier bin

1. Dans cet exemple, nous avons choisi Debug comme configuration de la solution

2. Définissez la plateforme de solution sur Any CPU

Une fois le projet ouvert, nous pouvons générer la solution. Ce processus créera un fichier DynamoSandbox.exe que vous pouvez exécuter.

La génération du projet restaurera les dépendances NuGet.

1. Sélectionnez Build > Build Solution

2. Vérifiez que la génération a réussi dans la fenêtre de sortie, elle devrait ressembler à ==== Build: 69 succeeded, 0 failed, 0 up-to-date, 0 skipped ====

Exécution d’une génération locale

Si Dynamo est généré correctement, un dossier bin est créé dans le dépôt Dynamo avec le fichier DynamoSandbox.exe. Dans notre cas, nous générons avec l’option Debug, donc le fichier exécutable est situé dans bin\AnyCPU\Debug. L’exécution de cette commande ouvrira une version locale de Dynamo.

1. L’exécutable DynamoSandbox que nous venons de générer. Exécutez cette commande pour démarrer Dynamo.

Nous sommes maintenant presque prêts à commencer à développer pour Dynamo.

Pour des instructions sur la génération de Dynamo pour d’autres plate-formes (par exemple Linux ou OS X), visitez cette page wiki.

Déboguer une version locale à l’aide de Visual Studio

Le débogage est un processus qui permet d’identifier, d’isoler et de corriger un bogue ou un problème. Une fois que Dynamo a été généré à partir de la source, nous pouvons utiliser plusieurs outils dans Visual Studio pour déboguer une application en cours d’exécution, le complément DynamoRevit par exemple. Nous pouvons analyser son code source pour trouver l’origine d’un problème, ou observer le code en cours d’exécution. Pour une explication plus détaillée sur la manière de déboguer et de parcourir le code dans Visual Studio, reportez-vous à la documentation de Visual Studio.

Pour l’application Dynamo autonome, DynamoSandbox, nous allons couvrir deux options de débogage :

• générer et démarrer Dynamo directement à partir de Visual Studio ;

• associer Visual Studio à un processus en cours d’exécution de Dynamo.

Démarrer Dynamo à partir de Visual Studio génère à nouveau la solution pour chaque session de débogage si nécessaire, donc si nous avons fait des changements à la source, ils seront incorporés lors du débogage. La solution Dynamo.All.sln étant toujours ouverte, sélectionnez Debug, AnyCPU et DynamoSandbox dans les menus déroulants, puis cliquez sur Start. Cela va générer Dynamo et démarrer un nouveau processus (DynamoSandbox.exe), et y attacher le débogueur de Visual Studio.

Générer et démarrer une application à partir de Visual Studio

1. Définissez la configuration sur Debug

2. Définissez la plate-forme sur Any CPU

3. Définissez le projet de démarrage sur DynamoSandbox

4. Cliquez sur Start pour commencer le processus de débogage

Il est également possible de déboguer un processus Dynamo déjà en cours d’exécution pour résoudre un problème lié à un graphique ouvert ou à un package spécifique. Pour ce faire, nous devons ouvrir les fichiers sources du projet dans Visual Studio et nous attacher à un processus Dynamo en cours d’exécution en utilisant l’élément de menu de débogage Attach to Process.

Attacher un processus en cours d’exécution à Visual Studio

1. Sélectionnez Debug > Attach to Process...

2. Choisissez DynamoSandbox.exe

3. Sélectionnez Attach

Dans les deux cas, nous attachons le débogueur à un processus que nous souhaitons déboguer. Nous pouvons définir des points d’arrêt dans le code avant ou après le démarrage du débogueur, ce qui entraînera une pause du processus immédiatement avant l’exécution de cette ligne de code. Si une exception non interceptée est levée lors du débogage, Visual Studio accède à l’emplacement où elle s’est produite dans le code source. Cette méthode est efficace pour rechercher des blocages simples, des exceptions non gérées et pour comprendre le flux d’exécution d’une application.

Lors du débogage de DynamoSandbox, nous avons placé un point d’arrêt dans le constructeur du nœud Color.ByARGB qui provoque une pause dans le processus Dynamo lorsque le nœud est instancié. Si ce nœud lance une exception ou provoque le blocage de Dynamo, nous pouvons parcourir chaque ligne du constructeur pour déterminer où le problème se produit.

1. Le point d’arrêt

2. La pile d’appels montre la fonction en cours d’exécution et les appels de fonction précédents

Dans la section suivante, Générer DynamoRevit à partir de la source, nous aborderons un exemple spécifique de débogage et expliquerons comment définir des points d’arrêt, parcourir le code et lire la pile d’appels.

Tirer la dernière version

Puisque la source de Dynamo est hébergée sur Github, la façon la plus simple de garder les fichiers source locaux à jour est de tirer les changements en utilisant les commandes git.

En utilisant la ligne de commande, définissez le répertoire courant du dépôt Dynamo :

cd C:\Users\username\Documents\GitHub\Dynamo

Remplacez "username" par votre nom d’utilisateur

Utilisez la commande suivante pour tirer les dernières modifications :

git pull origin master

1. Nous pouvons voir ici que le dépôt local a été mis à jour avec les modifications apportées par le dépôt distant.

En plus de tirer des mises à jour, il y a quatre autres flux de travail git avec lesquels il faut se familiariser.

• Dupliquer le dépôt Dynamo permet de créer une copie séparée de l’original. Tout changement effectué ici n’affectera pas le dépôt original et les mises à jour peuvent être récupérées ou soumises avec des demandes de tirage. Dupliquer n’est pas une commande git, mais un flux de travail que github ajoute. Le modèle de duplication et de tirage est l’un des flux de travail les plus courants pour contribuer à des projets open source en ligne. Cela vaut la peine de l’apprendre si vous voulez contribuer à Dynamo.

• Une branche permet de travailler sur des expériences ou de nouvelles fonctionnalités isolées des autres travaux dans les branches. Cela facilite l’envoi de demandes de tirage.

• Effectuez des commits fréquemment, après avoir terminé une unité de travail et après une modification qui pourrait être annulée. Un commit enregistre les changements dans le dépôt et sera visible lors d’une demande de tirage dans le dépôt principal de Dynamo.

• Créez des demandes de tirage lorsque les changements sont prêts à être officiellement proposés au dépôt principal de Dynamo.

L’équipe Dynamo a des instructions spécifiques sur la création de demandes de tirage. Reportez-vous à la section Demandes de tirage de cette documentation pour obtenir des informations plus détaillées sur les éléments à traiter.

Reportez-vous à cette page de documentation pour obtenir une liste de référence des commandes git.

Quel que soit le niveau d’expérience, la plateforme Dynamo est conçue pour que tous les utilisateurs soient des contributeurs. Il existe plusieurs options de développement qui ciblent des capacités et des niveaux de compétence différents, chacune avec ses forces et ses faiblesses selon l’objectif. Nous présentons ci-dessous les différentes options et comment les choisir.

Trois environnements de développement : Visual Studio, Python Editor et Code Block DesignScript

Quelles sont les options proposées ?

Les options de développement de Dynamo sont principalement réparties en deux catégories : pour Dynamo et dans Dynamo. Les deux catégories peuvent être considérées comme : « dans » Dynamo implique un contenu créé à l’aide de l’environnement de développement intégré (IDE) de Dynamo pour être utilisé dans Dynamo, et « pour » Dynamo implique l’utilisation d’outils externes pour créer du contenu qui sera importé dans Dynamo pour être utilisé. Bien que ce guide soit axé sur le développement pour Dynamo, les ressources pour tous les processus sont décrites ci-dessous.

Pour Dynamo

Ces nœuds permettent le plus haut degré de personnalisation. De nombreux packages sont créés avec cette méthode, et elle est nécessaire pour contribuer à la source de Dynamo. Le processus de génération sera abordé dans ce guide.

• Nœuds Zero-Touch

• Nœuds dérivés de NodeModel

• Extensions

Visual Studio est utilisé comme environnement de développement pour les nœuds Zero Touch et NodeModel dans les explications ci-dessous.

L’interface Visual Studio avec un projet que nous allons développer

Dans Dynamo

• Les blocs de code exposent DesignScript dans l’environnement de programmation visuel, ce qui permet des flux de travail de nœud et de script de texte flexibles. Une fonction dans un bloc de code peut être appelée par n’importe quel élément de l’espace de travail.

• Les nœuds personnalisés sont des conteneurs destinés à des ensembles de nœuds ou même à des graphiques entiers. Ils sont un moyen efficace de collecter les routines fréquemment utilisées et de les partager avec la communauté.

• Les nœuds Python sont une interface de script dans l’espace de travail de programmation visuelle, similaire aux blocs de code. Les bibliothèques Autodesk.DesignScript utilisent une notation par points similaire à DesignScript.

Le développement dans l’espace de travail de Dynamo est un outil puissant qui permet d’obtenir un retour immédiat.

Développement dans l’espace de travail Dynamo avec le nœud Python

Quels sont les avantages/inconvénients de chacun ?

Les options de développement de Dynamo ont été conçues pour répondre à la complexité d’un besoin de personnalisation. Que ce soit pour écrire un script récursif en Python ou pour générer une interface utilisateur de nœud entièrement personnalisée, il existe des options d’implémentation de code qui n’impliquent que ce qui est nécessaire pour être opérationnel.

Blocs de code, nœud Python et nœuds personnalisés dans Dynamo

Ces options sont simples pour écrire du code dans l’environnement de programmation visuelle Dynamo. L’espace de programmation visuelle Dynamo permet d’accéder à Python, DesignScript et de contenir plusieurs nœuds dans un nœud personnalisé.

Avec ces méthodes, vous pouvez :

• commencer à écrire des scripts Python ou DesignScript avec peu ou pas de configuration ;

• importer des bibliothèques Python dans Dynamo ;

• partager des blocs de code, des nœuds Python et des nœuds personnalisés avec la communauté Dynamo dans un package.

Nœuds Zero-Touch

Zero Touch fait référence à une méthode pointer-cliquer simple permettant d’importer des bibliothèques C#. Dynamo lit les méthodes publiques d’un fichier .dll et les convertit en nœuds Dynamo. Vous pouvez utiliser le Zero-Touch pour développer vos propres nœuds et packages personnalisés.

Avec cette méthode, vous pouvez :

• écrire des méthodes C# et les utiliser facilement comme nœuds dans Dynamo ;

• partager une bibliothèque C# en tant que nœuds avec la communauté Dynamo dans un package.

Nœuds dérivés de NodeModel

Ces nœuds permettent d’approfondir la structure de Dynamo. Ils sont basés sur la classe NodeModel et écrits en C#. Bien que cette méthode soit la plus souple et la plus puissante, la plupart des aspects du nœud doivent être définis de manière explicite et les fonctions doivent se trouver dans un ensemble séparé.

Avec cette méthode, vous pouvez :

• créer une interface utilisateur de nœuds entièrement personnalisable avec des curseurs, des images, des couleurs, etc. (p. ex. un nœud ColorRange) ;

• accéder et agir sur la zone de dessin Dynamo ;

• personnaliser la combinaison ;

• charger dans Dynamo comme un package.

Présentation du contrôle des versions de Dynamo et des modifications apportées à l’API (1.x → 2.x)

Comme Dynamo est régulièrement mis à jour, des modifications peuvent être apportées à une partie de l’API utilisée par un package. Il est important de suivre ces modifications pour s’assurer que les packages existants continuent à fonctionner correctement.

Autorisation de distribuer des binaires dans un package

Faites attention aux fichiers .dll inclus dans un package qui sont téléchargés dans le gestionnaire de package. Si l’auteur du package n’a pas créé le fichier .dll, il doit disposer des droits nécessaires pour le partager.

Si un package comprend des binaires, les utilisateurs doivent être avertis lors du téléchargement que celui-ci en contient.

Quel est le but de ce guide ?

L’objectif de ce guide est de vous aider à parcourir les différentes possibilités de développement en C# pour Dynamo, de la création de nœuds Zero-Touch à la génération d’extensions.

La source Dynamo sur GitHub

Quelles sont les ressources supplémentaires que nous mettons à la disposition des développeurs ?

Dynamo : téléchargez les dernières versions stables et quotidiennes de Dynamo

https://dynamobuilds.com/

Dynamo GitHub : Dynamo est un projet de développement open source sur GitHub.

https://github.com/DynamoDS/Dynamo

Wiki Dynamo Github : il s’agit de la principale ressource pour la documentation destinée aux développeurs.

https://github.com/DynamoDS/Dynamo/wiki

Normes de dénomination des nœuds : elles fournissent des normes et des directives pour la dénomination des catégories, des nœuds et des ports d’entrée et de sortie dans Dynamo.

https://github.com/DynamoDS/Dynamo/wiki/Naming-Standards

Guide de l’API/du langage Dynamo : la documentation de l’API Dynamo couvre actuellement les fonctionnalités de base.

https://dynamods.github.io/DynamoAPI/

DynamoBIM : la meilleure source d’informations supplémentaires, de contenu de formation et de forums est le site Web DynamoBIM.

https://dynamobim.org

Dictionnaire Dynamo : une base de données consultable de tous les nœuds Dynamo.

https://dictionary.dynamobim.com/

Guide du langage DesignScript : Guide PDF pour la syntaxe DesignScript.

PDF

Comment puis-je suggérer des modifications à ce guide ?

Cette documentation est ouverte aux suggestions. Ces modifications peuvent être effectuées directement dans Github en créant des demandes de modification.

Avec un projet Visual Studio opérationnel, nous allons voir comment générer un nœud personnalisé qui crée une grille rectangulaire de cellules. Bien que nous puissions créer ce nœud avec plusieurs nœuds standard, il s’agit d’un outil utile qui peut être facilement contenu dans un nœud Zero-Touch. Contrairement aux lignes de grille, les cellules peuvent être mises à l’échelle autour de leurs points centraux, interrogées pour leurs sommets d’angle ou créées dans des faces.

Cet exemple aborde quelques-unes des caractéristiques et des concepts à prendre en compte lors de la création d’un nœud Zero-Touch. Après avoir générer le nœud personnalisé et l’avoir ajouté à Dynamo, assurez-vous de consulter la page Aller plus loin avec Zero-Touch pour obtenir plus de détails sur les valeurs d’entrée par défaut, le renvoi de valeurs multiples, la documentation, les objets, l’utilisation des types de géométrie Dynamo et les migrations.

Noeud de grille rectangulaire personnalisé

Pour commencer à générer le nœud de grille, créez un nouveau projet de bibliothèque de classes Visual Studio. Reportez-vous à la page Mise en route pour obtenir un guide détaillé de la configuration d’un projet.

1. Choisissez Class Library comme type de projet

2. Nommez le projet CustomNodes

Comme nous allons créer une géométrie, nous devons référencer le package NuGet approprié. Installez le package ZeroTouchLibrary à partir du gestionnaire de package Nuget. Ce package est nécessaire pour l’instruction using Autodesk.DesignScript.Geometry;.

1. Recherchez le package ZeroTouchLibrary.

2. Nous utiliserons ce nœud dans la version actuelle de Dynamo Studio, qui est la 1.3. Sélectionnez la version du package qui correspond à cette version.

3. Notez que nous avons également renommé le fichier de classe en Grids.cs.

Ensuite, nous devons établir un espace de noms et une classe dans lesquels la méthode RectangularGrid sera intégrée. Le nœud sera nommé dans Dynamo en fonction des noms de la méthode et de la classe. Nous n’avons pas besoin de copier ceci dans Visual Studio pour le moment.

using Autodesk.DesignScript.Geometry;
using System.Collections.Generic;

namespace CustomNodes
{
    public class Grids
    {
        public static List<Rectangle> RectangularGrid(int xCount, int yCount)
        {
        //The method for creating a rectangular grid will live in here
        }
    }
}

Autodesk.DesignScript.Geometry; fait référence au fichier ProtoGeometry.dll du package et ZeroTouchLibrary System.Collections.Generic est nécessaire pour créer des listes

Nous pouvons maintenant ajouter la méthode pour dessiner les rectangles. Le fichier de classe doit ressembler à ceci et peut être copié dans Visual Studio.

using Autodesk.DesignScript.Geometry;
using System.Collections.Generic;

namespace CustomNodes
{
    public class Grids
    {
        public static List<Rectangle> RectangularGrid(int xCount, int yCount)
        {
            double x = 0;
            double y = 0;

            var pList = new List<Rectangle>();

            for (int i = 0; i < xCount; i++)
            {
                y++;
                x = 0;
                for (int j = 0; j < yCount; j++)
                {
                    x++;
                    Point pt = Point.ByCoordinates(x, y);
                    Vector vec = Vector.ZAxis();
                    Plane bP = Plane.ByOriginNormal(pt, vec);
                    Rectangle rect = Rectangle.ByWidthLength(bP, 1, 1);
                    pList.Add(rect);
                }
            }
            return pList;
        }
    }
}

Si le projet ressemble à ceci, essayez de générer le .dll.

1. Choisissez Générer > Générer une solution

Vérifiez si le dossier bin du projet contient un .dll. Si la génération est réussie, nous pouvons ajouter le .dll à Dynamo.

1. Le nœud RectangularGrids personnalisé dans la bibliothèque Dynamo

2. Le nœud personnalisé sur la zone de dessin

3. Le bouton Ajouter permet d’ajouter le .dll à Dynamo

Modifications de nœuds personnalisé

Dans l’exemple ci-dessus, nous avons créé un nœud assez simple qui définit essentiellement la méthode RectangularGrids. Cependant, nous pouvons vouloir créer des infobulles pour les ports d’entrée ou donner au nœud un résumé comme les nœuds Dynamo standard. L’ajout de ces fonctionnalités aux nœuds personnalisés les rend plus faciles à utiliser, en particulier si un utilisateur souhaite les rechercher dans la bibliothèque.

1. Une valeur d’entrée par défaut

2. Une Info-bulle pour l’entrée xCount

Le nœud RectangularGrid a besoin de certaines de ces caractéristiques de base. Dans le code ci-dessous, nous avons ajouté des descriptions des ports d’entrée et de sortie, un résumé et des valeurs d’entrée par défaut.

using Autodesk.DesignScript.Geometry;
using System.Collections.Generic;

namespace CustomNodes
{
    public class Grids
    {
        /// <summary>
        /// This method creates a rectangular grid from an X and Y count.
        /// </summary>
        /// <param name="xCount">Number of grid cells in the X direction</param>
        /// <param name="yCount">Number of grid cells in the Y direction</param>
        /// <returns>A list of rectangles</returns>
        /// <search>grid, rectangle</search>
        public static List<Rectangle> RectangularGrid(int xCount = 10, int yCount = 10)
        {
            double x = 0;
            double y = 0;

            var pList = new List<Rectangle>();

            for (int i = 0; i < xCount; i++)
            {
                y++;
                x = 0;
                for (int j = 0; j < yCount; j++)
                {
                    x++;
                    Point pt = Point.ByCoordinates(x, y);
                    Vector vec = Vector.ZAxis();
                    Plane bP = Plane.ByOriginNormal(pt, vec);
                    Rectangle rect = Rectangle.ByWidthLength(bP, 1, 1);
                    pList.Add(rect);
                    Point cPt = rect.Center();
                }
            }
            return pList;
        }
    }
}

• Donnez aux entrées des valeurs par défaut en attribuant des valeurs aux paramètres de la méthode : RectangularGrid(int xCount = 10, int yCount = 10).

• Créez des info-bulles d’entrée et de sortie, des mots-clés de recherche et un résumé avec la documentation XML précédée de ///.

Pour ajouter des info-bulles, vous devez disposer d’un fichier XML dans le répertoire du projet. Un .xml peut être généré automatiquement par Visual Studio en activant l’option.

1. Activez ici le fichier de documentation XML et indiquez un chemin d’accès au fichier. Cela génère un fichier XML.

Et voilà ! Nous avons créé un nouveau nœud doté de plusieurs fonctions standard. Le chapitre suivant, Bases de Zero-Touch, décrit plus en détail le développement des nœuds Zero-Touch et les problèmes à prendre en compte.

Avant de se lancer dans le développement, il est important d’établir des bases solides pour un nouveau projet. Il existe plusieurs modèles de projets dans la communauté des développeurs Dynamo qui sont d’excellents points de départ, mais il est encore plus utile de savoir comment démarrer un projet à partir de zéro. La génération d’un projet à partir de zéro permet de mieux comprendre le processus de développement.

Créer un projet Visual Studio

Visual Studio est un environnement IDE puissant dans lequel vous pouvez créer un projet, ajouter des références, générer des .dlls et déboguer. Lors de la création d’un projet, Visual Studio crée également une solution, une structure pour l’organisation des projets. Plusieurs projets peuvent exister au sein d’une même solution et peuvent être créés ensemble. Pour créer un nœud ZeroTouch, nous devons démarrer un nouveau projet Visual Studio dans lequel nous écrirons une bibliothèque de classes en C# et générerons un .dll.

La fenêtre Nouveau projet dans Visual Studio

1. Commencez par ouvrir Visual Studio et créez un projet : File > New > Project.

2. Choisissez le modèle de projet Class Library.

3. Donnez un nom au projet (nous avons nommé le projet MyCustomNode).

4. Définissez le chemin d’accès au fichier de votre projet. Dans cet exemple, nous le laisserons à l’emplacement par défaut.

5. Sélectionnez Ok.

Visual Studio crée et ouvre automatiquement un fichier C#. Donnez-lui un nom approprié, configurez l’espace de travail et remplacez le code par défaut par cette méthode de multiplication.

 namespace MyCustomNode
 {
     public class SampleFunctions
     {
         public static double MultiplyByTwo(double inputNumber)
         {
             return inputNumber * 2.0;
         }
     }
 }

1. Ouvrez l’explorateur de solutions et les fenêtres de sortie à partir de View.

2. Renommez le fichier Class1.cs en SampleFunctions.cs dans l’explorateur de solutions sur la droite.

3. Ajoutez le code ci-dessus pour la fonction de multiplication. Nous verrons plus tard comment Dynamo lira vos classes C#.

4. L’explorateur de solutions : il vous permet d’accéder à tous les éléments de votre projet.

5. La fenêtre de sortie : nous en aurons besoin plus tard pour voir si la génération s’est bien déroulée.

L’étape suivante consiste à générer le projet, mais avant cela, nous devons vérifier quelques paramètres. Tout d’abord, assurez-vous que Any CPU ou x64 est sélectionné comme plateforme cible et que la case Prefer 32-bit n’est pas cochée dans les propriétés du projet.

1. Ouvrez les propriétés du projet en sélectionnant Project > "ProjectName" Properties.

2. Sélectionnez la page Build.

3. Sélectionnez Any CPU ou x64 dans le menu déroulant.

4. Assurez-vous que la case Prefer 32-bit n’est pas cochée.

Nous pouvons maintenant générer le projet pour créer un .dll. Pour ce faire, sélectionnez Build Solution dans le menu Build ou utilisez le raccourci CTRL+SHIFT+B.

1. Sélectionnez Build > Build Solution.

2. Vous pouvez déterminer si votre projet a été créé correctement en cochant la fenêtre Sortie.

Si le projet a été créé correctement, un .dll nommé MyCustomNode figure dans le dossier bin du projet. Pour cet exemple, nous avons laissé le chemin d’accès au fichier du projet tel qu’il est défini par défaut par Visual Studio, à savoir c:\users\username\documents\visual studio 2015\Projects. Examinons la structure de fichiers du projet.

1. Le dossier bin contient le .dll créé à partir de Visual Studio.

2. Le fichier du projet Visual Studio.

3. Le fichier de classe.

4. La configuration de notre solution étant définie sur Debug, le .dll sera créé dans bin\Debug.

Nous pouvons maintenant ouvrir Dynamo et importer le .dll. Avec la fonction Ajouter, accédez à l’emplacement bin du projet et sélectionnez le .dll à ouvrir.

1. Cliquez sur le bouton Ajouter pour importer un fichier .dll.

2. Accédez à l’emplacement du projet. Notre projet se trouve dans le chemin d’accès par défaut de Visual Studio : C:\Users\username\Documents\Visual Studio 2015\Projects\MyCustomNode.

3. Sélectionnez le MyCustomNode.dll à importer.

4. Cliquez sur Open pour charger le .dll.

Si une catégorie est créée dans la bibliothèque appelée MyCustomNode, le fichier .dll a été importé avec succès ! Cependant, Dynamo a créé deux nœuds alors que nous n’en voulions qu’un seul. Dans la section suivante, nous allons expliquer pourquoi cela se produit et comment Dynamo lit un fichier .dll.

1. MyCustomNode dans la bibliothèque Dynamo. La catégorie Bibliothèque est déterminée par le nom .dll.

2. SampleFunctions.MultiplyByTwo dans la zone de dessin.

Lecture des classes et des méthodes par Dynamo

Lorsque Dynamo charge un fichier .dll, il expose toutes les méthodes statiques publiques sous forme de nœuds. Les constructeurs, les méthodes et les propriétés seront transformés respectivement en nœuds de création, d’action et de requête. Dans notre exemple de multiplication, la méthode MultiplyByTwo() devient un nœud d’action dans Dynamo. Ceci est dû au fait que le nœud a été nommé en fonction de sa méthode et de sa classe.

1. L’entrée est nommée inputNumber en fonction du nom du paramètre de la méthode.

2. La sortie est nommée double par défaut, car il s’agit du type de données renvoyé.

3. Le nœud est nommé SampleFunctions.MultiplyByTwo car il s’agit des noms de classe et de méthode.

Dans l’exemple ci-dessus, le nœud supplémentaire de création SampleFunctions a été créé, car nous n’avons pas fourni explicitement de constructeur et par conséquent un constructeur a été automatiquement créé. Nous pouvons éviter cela en créant un constructeur privé vide dans notre classe SampleFunctions.

namespace MyCustomNode
{
    public class SampleFunctions
    {
        //The empty private constructor.
        //This will be not imported into Dynamo.
        private SampleFunctions() { }

        //The public multiplication method. 
        //This will be imported into Dynamo.
        public static double MultiplyByTwo(double inputNumber)
        {
            return inputNumber * 2.0;
        }
    }
}

1. Dynamo a importé notre méthode en tant que nœud de création

Ajouter des références de package Dynamo NuGet

Le nœud de multiplication est très simple et aucune référence à Dynamo n’est nécessaire. Si nous voulons accéder à l’une des fonctionnalités de Dynamo pour créer une géométrie par exemple, nous devrons faire référence aux packages NuGet de Dynamo.

• ZeroTouchLibrary : package permettant de générer des bibliothèques de nœuds Zero-Touch pour Dynamo, qui contient les bibliothèques suivantes : DynamoUnits.dll, ProtoGeometry.dll.

• WpfUILibrary : package permettant de générer des bibliothèques de nœuds pour Dynamo avec une interface utilisateur personnalisée dans WPF, qui contient les bibliothèques suivantes : DynamoCoreWpf.dll, CoreNodeModels.dll, CoreNodeModelWpf.dll.

• DynamoServices : bibliothèque DynamoServices pour Dynamo.

• Core : infrastructure de test unitaire et système pour Dynamo qui contient les bibliothèques suivantes : DSIronPython.dll, DynamoApplications.dll, DynamoCore.dll, DynamoInstallDetective.dll, DynamoShapeManager.dll, DynamoUtilities.dll, ProtoCore.dll, VMDataBridge.dll.

• Tests : infrastructure de test unitaire et système pour Dynamo qui contient les bibliothèques suivantes : DynamoCoreTests.dll, SystemTestServices.dll, TestServices.dll.

• DynamoCoreNodes : package pour la génération de nœuds de noyau pour Dynamo qui contient les bibliothèques suivantes : Analysis.dll, GeometryColor.dll, DSCoreNodes.dll.

Pour référencer ces packages dans un projet Visual Studio, téléchargez le package à partir de NuGet à l’aide des liens ci-dessus et référencez manuellement les fichiers .dll ou utilisez le gestionnaire de package NuGet dans Visual Studio. Nous pouvons d’abord voir comment les installer avec NuGet dans Visual Studio.

1. Ouvrez le gestionnaire de package NuGet en sélectionnant Tools > NuGet Package Manager > Manage NuGet Packages for Solution....

Il s’agit du gestionnaire de package NuGet. Cette fenêtre indique les packages qui ont été installés pour le projet et permet à l’utilisateur d’en rechercher d’autres. Si une nouvelle version du package DynamoServices est publiée, les packages peuvent être mis à jour à partir d’ici ou rétablis à une version antérieure.

1. Sélectionnez Parcourir et recherchez DynamoVisualProgramming pour faire apparaître les packages Dynamo.

2. Les packages Dynamo. En sélectionnant l’un d’entre eux, vous verrez sa version actuelle et une description de son contenu.

3. Sélectionnez la version du package dont vous avez besoin et cliquez sur installer. Cela permet d’installer un package pour le projet spécifique sur lequel vous travaillez. Puisque nous utilisons la dernière version stable de Dynamo (version 1.3), choisissez la version du package correspondante.

Pour ajouter manuellement un package téléchargé à partir du navigateur, ouvrez le gestionnaire des références à partir de l’explorateur de solutions et recherchez le package.

1. Cliquez avec le bouton droit de la souris sur References et sélectionnez Add Reference.

2. Sélectionnez Browse pour accéder à l’emplacement du package.

Maintenant que Visual Studio est configuré correctement et que nous avons réussi à ajouter un .dll à Dynamo, nous disposons d’une base solide pour les concepts à venir. Ce n’est que le début, alors poursuivez votre lecture pour en savoir plus sur la création d’un nœud personnalisé.

Les fichiers sources de DynamoRevit sont également hébergés sur DynamoDS Github pour que les développeurs puissent apporter des contributions et générer des versions bêta. Générer DynamoRevit à partir des sources suit généralement le même processus que Dynamo à l’exception de quelques détails importants :

• DynamoRevit fait référence aux assemblages Dynamo, qui doivent donc être générés avec les packages NuGet correspondants. Par exemple, DynamoRevit 2.x ne se chargera pas dans Dynamo 1.3.

• DynamoRevit est spécifique aux versions de Revit, par exemple, la branche DynamoRevit 2018 devrait fonctionner sur Revit 2018.

Pour ce guide, nous utiliserons ce qui suit :

• Revit 2023 ;

• la dernière version de DynamoRevit sur la branche Revit2023 ;

• la dernière version de Dynamo.

Pour assurer une génération réussie, nous allons cloner et générer les dépôts Dynamo et DynamoRevit pour les utiliser dans ce guide.

Remarque : générer Dynamo manuellement avant DynamoRevit n’est nécessaire que si vous générez Dynamo 1.x et DynamoRevit 1.x. Les versions plus récentes du dépôt DynamoRevit s’appuient sur le gestionnaire de package NuGet pour les dépendances de Dynamo nécessaires à la génération. Bien qu’une génération de DynamoRevit 2.x ne nécessite pas de tirer Dynamo manuellement, vous aurez toujours besoin du noyau dlls ailleurs pour exécuter DynamoRevit addin. Il est donc préférable de tirer et de générer Dynamo. Pour en savoir plus, consultez la rubrique ci-dessous : Générer le dépôt avec Visual Studio

Localiser le dépôt DynamoRevit sur Github

Le code du projet DynamoRevit se trouve dans un dépôt séparé sur Github du code source principal de Dynamo. Ce dépôt contient les fichiers sources pour les nœuds spécifiques à Revit et le complément Revit qui charge Dynamo. Les générations de DynamoRevit pour différentes versions de Revit (2016, 2017 ou 2018, par exemple) sont organisées comme des branches dans le dépôt.

La source de DynamoRevit est hébergée ici : https://github.com/DynamoDS/DynamoRevit

1. Cloner ou télécharger le dépôt

2. Les branches de DynamoRevit font référence aux versions de Revit

Cloner le dépôt en utilisant git

De la même manière que pour le dépôt Dynamo, nous allons utiliser la commande git clone pour cloner DynamoRevit et spécifier la branche qui correspond à notre version de Revit. Pour commencer, nous allons ouvrir une interface en ligne de commande et placer le répertoire courant là où nous voulons cloner les fichiers.

cd C:\Users\username\Documents\GitHub change le répertoire actuel

Remplacez username par votre nom d’utilisateur

Nous pouvons maintenant cloner le dépôt dans ce répertoire. Même si nous devons spécifier une branche du dépôt, nous pouvons basculer vers cette branche après le clonage.

git clone https://github.com/DynamoDS/DynamoRevit.git clone le dépôt à partir d’une URL distante et bascule par défaut sur la branche master.

Une fois que le clonage du dépôt est terminé, changez le répertoire courant en dossier du dépôt et passez à la branche qui correspond à la version installée de Revit. Pour cet exemple, nous utilisons Revit RC2.13.1_Revit2023. Toutes les branches distantes peuvent être consultées sur la page Github dans le menu déroulant Branche.

cd C:\Users\username\Documents\GitHub\DynamoRevit change le répertoire en DynamoRevit. git checkout RC2.13.1_Revit2023 définit la branche actuelle sur RC2.13.1_Revit2023. git branch vérifie la branche sur laquelle nous nous trouvons et affiche les autres branches qui existent localement.

La branche avec un astérisque est celle qui est en cours d’extraction. La branche Revit2018 est affichée, car nous l’avons précédemment extraite, elle existe donc localement.

Il est important de choisir la bonne branche du dépôt pour s’assurer que lorsque le projet sera générer dans Visual Studio, il fera référence aux assemblages dans la bonne version du répertoire d’installation de Revit, à savoir RevitAPI.dll et RevitAPIUI.dll.

Générer un dépôt à l’aide de Visual Studio

Avant de générer le dépôt, nous devons restaurer les packages NuGet avec le fichier restorepackages.bat situé dans le dossier src. Ce fichier .bat utilise le gestionnaire de package nuget pour tirer les fichiers binaires intégrés de Dynamo Core, dont DynamoRevit a besoin. Vous pouvez également choisir de les générer manuellement, à condition de ne faire que des changements dans DynamoRevit et non dans Dynamo Core. Cela permet de démarrer plus rapidement. Veillez à exécuter ce fichier en tant qu’administrateur.

1. Cliquez avec le bouton droit de la souris sur restorepackages.bat et sélectionnez Run as administrator.

Si les packages sont restaurés avec succès, un dossier packages sera ajouté au dossier src avec les derniers packages NuGet bêta.

1. La dernière version bêta des packages Dynamo NuGet

Une fois les packages restaurés, ouvrez le fichier de solution DynamoRevit.All.sln Visual Studio dans src et générez la solution. La génération peut initialement rencontrer des problèmes pour trouver AssemblySharedInfo.cs. Si c’est le cas, exécutez à nouveau la génération pour résoudre ce problème.

1. Sélectionnez Build > Build Solution.

2. Vérifiez que la génération a réussi dans la fenêtre de sortie. Un message devrait indiquer ===== Build: 13 succeeded, 0 failed, 0 up-to-date, 0 skipped =====.

Exécuter une génération locale de DynamoRevit dans Revit

Revit requiert un fichier de complément pour reconnaître DynamoRevit, ce que le programme d’installation créerait automatiquement. Dans le développement, nous devons créer manuellement un fichier de complément qui pointe vers la génération de DynamoRevit que nous voulons utiliser, en particulier l’assemblage DynamoRevitDS.dll. Nous devons également faire pointer DynamoRevit vers une génération de Dynamo.

Créez un fichier Dynamo.addin dans le dossier des compléments Revit situé dans C:\ProgramData\Autodesk\Revit\Addins\2023. Nous avions déjà installé une version de DynamoRevit, nous allons donc simplement éditer le fichier existant pour qu’il pointe vers la nouvelle génération.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<RevitAddIns>
<AddIn Type="Application">
<Name>Dynamo For Revit</Name>
<Assembly>"C:\Users\username\Documents\GitHub\DynamoRevit\bin\AnyCPU\Debug\Revit\DynamoRevitDS.dll"</Assembly>
<AddInId>8D83C886-B739-4ACD-A9DB-1BC78F315B2B</AddInId>
<FullClassName>Dynamo.Applications.DynamoRevitApp</FullClassName>
<VendorId>ADSK</VendorId>
<VendorDescription>Dynamo</VendorDescription>
</AddIn>
</RevitAddIns>

• Spécifiez le chemin d’accès au fichier de DynamoRevitDS.dll dans <Assembly>...</Assembly>.

Nous pouvons également faire en sorte que le complément charge le sélecteur de version au lieu d’un assemblage spécifique.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<RevitAddIns>
<AddIn Type="Application">
<Name>Dynamo For Revit</Name>
<Assembly>"C:\Users\username\Documents\GitHub\DynamoRevit\bin\AnyCPU\Debug\Revit\DynamoRevitVersionSelector.dll"</Assembly>
<AddInId>8D83C886-B739-4ACD-A9DB-1BC78F315B2B</AddInId>
<FullClassName>Dynamo.Applications.VersionLoader</FullClassName>
<VendorId>ADSK</VendorId>
<VendorDescription>Dynamo</VendorDescription>
</AddIn>
</RevitAddIns>

• Définissez le chemin d’accès au fichier <Assembly>...</Assembly> sur DynamoRevitVersionSelector.dll.

• <FullClassName>...</FullClassName> spécifie quelle classe doit être instanciée à partir de l’assemblage que nous avons pointé avec le chemin de l’élément d’assemblage ci-dessus. Cette classe sera le point d’entrée de notre complément.

En outre, nous devons supprimer la version existante de Dynamo qui est livrée avec Revit. Pour ce faire, accédez à C:\\Program Files\Autodesk\Revit 2023\AddIns et supprimez les deux dossiers qui contiennent Dynamo : DynamoForRevit et DynamoPlayerForRevit. Vous pouvez les supprimer ou les sauvegarder dans un dossier séparé si vous avez besoin de récupérer la version originale de Dynamo for Revit.

La deuxième étape consiste à ajouter un chemin d’accès au fichier Dynamo.config dans le dossier bin de DynamoRevit pour les assemblages de Dynamo Core. DynamoRevit les chargera lorsque le complément sera ouvert dans Revit. Ce fichier de configuration vous permet de faire pointer votre complément DynamoRevit vers différentes versions de Dynamo Core pour développer et tester des changements à la fois dans Dynamo Core et dans DynamoRevit.

Le code devrait ressembler à ceci :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
     <add key="DynamoRuntime" value="C:\Users\username\Documents\GitHub\Dynamo\bin\AnyCPU\Debug"/>
  </appSettings>
</configuration>

• Ajoutez le chemin d’accès au répertoire du dossier bin à <add key/>.

Nous avons cloné et généré Dynamo juste avant ce guide pour nous assurer qu’il fonctionnera correctement avec DynamoRevit. Le chemin d’accès au répertoire pointe vers cette génération.

Désormais, lorsque nous ouvrons Revit, un complément Dynamo doit se trouver dans l’onglet Gérer.

1. Sélectionnez Manage

2. Cliquez sur l’icône du complément Dynamo

3. Une instance de DynamoRevit

Si une boîte de dialogue d’erreur s’affiche et indique des assemblages manquants, il est probable qu’il existe une différence entre les versions de DynamoCore sur lesquelles vous avez effectué la génération et celles que vous chargez au moment de l’exécution. Par exemple, DynamoRevit avec les derniers packages bêta 2.0 de DynamoCore ne fonctionnera pas si vous essayez de le démarrer en utilisant les .dll de Dynamo 1.3. Assurez-vous que les deux dépôts sont de la même version et que DynamoRevit tire une version correspondante des dépendances nuget. Celles-ci sont définies dans le fichier package.json du dépôt DynamoRevit.

Déboguer DynamoRevit avec Visual Studio

Dans la section précédente, Générer Dynamo à partir de la source, nous avons brièvement présenté le débogage dans Visual Studio et la manière d’attacher Visual Studio à un processus. En utilisant une exception dans le nœud Wall.ByCurveAndHeight comme exemple, nous verrons comment s’attacher à un processus, définir des points d’arrêt, parcourir le code et utiliser la pile d’exécution pour déterminer la source de l’exception. Ces outils de débogage s’appliquent généralement aux flux de travail de développement .net et méritent d’être explorés en dehors de ce guide.

• Attacher au processus lie une application en cours d’exécution à Visual Studio pour le débogage. Si vous souhaitez déboguer un comportement qui se produit dans une version de DynamoRevit, vous pouvez ouvrir les fichiers source DynamoRevit dans Visual Studio et attacher le processus Revit.exe, qui est le processus parent du complément DynamoRevit. Visual Studio utilise un fichier de symboles (.pbd) pour faire le lien entre les assemblages que DynamoRevit exécute et le code source.

• Les points d’arrêt établissent des lignes dans le code source où l’application fera une pause avant de s’exécuter. Si un nœud provoque le blocage de DynamoRevit ou renvoie un résultat inattendu, nous pouvons ajouter un point d’arrêt à la source du nœud pour mettre le processus en pause, entrer dans le code et inspecter les valeurs en direct des variables jusqu’à ce que nous trouvions la racine du problème.

• Parcourir le code permet de parcourir le code source ligne par ligne. Nous pouvons exécuter les fonctions une par une, passer à un appel de fonction ou quitter la fonction en cours d’exécution.

• La pile d’exécution affiche la fonction qu’un processus est en train d’exécuter par rapport aux appels de fonction précédents qui ont invoqué cet appel de fonction. Visual Studio dispose d’une fenêtre Pile d’exécution pour afficher cela. Par exemple, si nous rencontrons une exception en dehors du code source, nous pouvons voir le chemin vers le code appelant dans la pile d’exécution.

  2,000 Things You Should Know About C# (2 000 choses que vous devriez savoir sur le C#) contient des explications plus approfondies des piles d’exécution.

Le nœud Wall.ByCurveAndHeight lève une exception lorsqu’il reçoit une PolyCurve comme courbe d’entrée, avec le message suivant : « To BSPlineCurve Not Implemented » (Vers BSPlineCurve, non implémenté). Avec le débogage, nous pouvons comprendre pourquoi exactement le nœud n’accepte pas ce type de géométrie comme entrée pour le paramètre de courbe. Pour cet exemple, nous supposons que DynamoRevit a été généré avec succès et qu’il peut être exécuté en tant que complément pour Revit.

1. Le nœud Wall.ByCurveAndHeight lève une exception

Commencez par ouvrir le fichier de solution DynamoRevit.All.sln, démarrez Revit et démarrez le complément DynamoRevit. Attachez ensuite Visual Studio au processus Revit à l’aide de la fenêtre Attach to Process.

Revit et DynamoRevit doivent être en cours d’exécution pour apparaître comme un processus disponible.

1. Ouvrez la fenêtre Attach to Process en sélectionnant Debug > Attach to Process...

2. Définissez Transport sur Default

3. Sélectionnez Revit.exe

4. Sélectionnez Attach

Visual Studio étant attaché à Revit, ouvrez le code source Wall.ByCurveAndHeight dans Wall.cs. Nous pouvons le trouver dans l’explorateur de solutions sous Libraries > RevitNodes > Elements dans la partie Public static constructors du fichier. Définissez un point d’arrêt dans le constructeur du type de mur de sorte que lorsque le nœud est exécuté dans Dynamo, le processus s’interrompt et nous pouvons parcourir chaque ligne de code individuellement. En général, les constructeurs du type Dynamo Zero-Touch commencent par By<parameters>.

1. Le fichier de classe avec le constructeur pour Wall.ByCurveAndHeight.

2. Définissez un point d’arrêt en cliquant à gauche du numéro de ligne ou en cliquant avec le bouton droit de la souris sur la ligne de code et en sélectionnant Breakpoint > Insert Breakpoint.

Une fois le point d’arrêt défini, nous devons exécuter le processus avec la fonction Wall.ByCurveAndHeight. La fonction peut être exécutée à nouveau dans Dynamo en reconnectant un fil à l’un de ses ports, ce qui forcera le nœud à s’exécuter à nouveau. Le point d’arrêt sera atteint dans Visual Studio.

1. L’icône du point d’arrêt change lorsqu’il est atteint

2. La fenêtre de la pile d’exécution montre la méthode suivante

Nous allons maintenant parcourir chaque ligne du constructeur jusqu’à ce que nous rencontrions l’exception. Le code surligné en jaune est la prochaine instruction à exécuter.

1. Les outils de débogage pour parcourir le code

2. Appuyez sur Step Over pour exécuter le code en surbrillance, puis suspendez l’exécution après le retour de la fonction

3. La prochaine instruction à exécuter est indiquée par le texte surligné en jaune et la flèche

Si nous continuons à parcourir la fonction, nous atteindrons l’exception qui s’est affichée dans la fenêtre DynamoRevit. En regardant la fenêtre de la pile d’exécution, nous pouvons voir que l’exception a été levée à l’origine à partir d’une méthode appelée Autodesk.Revit.CurveAPIUtils.CreateNurbsCurve. Heureusement, l’exception est gérée ici, de sorte que Dynamo ne se bloque pas. Le processus de débogage a permis de contextualiser le problème en nous amenant à une autre méthode dans le code source.

Comme il ne s’agit pas d’une bibliothèque open source, nous ne pouvons pas y apporter de modifications. Maintenant que nous avons plus d’informations, nous pouvons signaler le problème avec plus de contexte en soumettant un problème Git ou nous pouvons proposer une solution alternative pour résoudre ce problème en faisant une demande de tirage.

1. Lorsque nous atteignons l’instruction à l’origine de l’exception dans Walls.cs, le processus de débogage nous rapproche le plus possible de l’origine du problème dans le code utilisateur dans ProtoToRevitCurve.cs

2. L’instruction à l’origine de l’exception dans ProtoToRevitCurve.cs

3. Dans la pile d’exécution, nous pouvons voir que l’exception provient d’un code non-utilisateur

4. Une fenêtre contextuelle nous donnant des informations sur l’exception

Ce processus peut être appliqué à tous les fichiers sources avec lesquels nous travaillons. Si nous développons une bibliothèque de nœuds Zero-Touch pour Dynamo Studio, nous pouvons ouvrir la source de la bibliothèque et attacher un processus Dynamo pour déboguer la bibliothèque de nœuds. Même si vous ne rencontre pas de problème, le débogage est un excellent moyen d’explorer le code et de découvrir comment les choses fonctionnent.

Tirer la dernière version

Ce processus est presque identique à celui du tirage de modifications pour Dynamo, sauf que nous devons nous assurer que nous sommes sur la bonne branche. Utilisez la commande git branch dans le dépôt DynamoRevit pour voir quelles branches sont disponibles localement et lesquelles sont actuellement vérifiées.

cd C:\Users\username\Documents\GitHub\DynamoRevit place le répertoire courant dans le dépôt DynamoRevit. git branch vérifie que nous sommes sur la bonne branche, RC2.13.1_Revit2023. git pull origin RC2.13.1_Revit2023 tire les changements de la branche d’origine distante RC2.13.1_Revit2023.

L’origine pointe simplement vers l’url originale que nous avons clonée.

Nous devons être attentifs à la branche actuelle et à la branche de tirage pour éviter de tirer les changements de RC2.13.1_Revit2023 vers Revit2018 par exemple.

Comme indiqué dans la section Générer Dynamo à partir de la source, lorsque nous sommes prêts à soumettre une modification au dépôt DynamoRevit, nous pouvons créer une demande de tirage en suivant les instructions de l’équipe Dynamo décrites dans la section Demandes de tirage.

Exécuter des scripts Python dans des nœuds Zero-Touch (C#)

Si vous êtes à l’aise avec l’écriture de scripts en Python et que vous voulez plus de fonctionnalités à partir des nœuds Python standard de Dynamo, nous pouvons utiliser Zero-Touch pour créer les nôtres. Commençons par un exemple simple qui nous permet de faire passer un script python sous la forme d’une chaîne à un nœud Zero-Touch où le script est exécuté et un résultat est renvoyé. Cette étude de cas s’appuie sur les guides et les exemples de la section Mise en route. Reportez-vous à ces derniers si vous êtes novice en matière de création de nœuds Zero-Touch.

Un nœud Zero-Touch qui exécute une chaîne de script Python

Moteur Python

Ce nœud s’appuie sur une instance du moteur de script IronPython. Pour faire cela, nous devons référencer quelques assemblages supplémentaires. Suivez les étapes ci-dessous pour configurer un modèle de base dans Visual Studio :

• créez un projet de classe Visual Studio ;

• ajoutez une référence au IronPython.dll situé dans C:\Program Files (x86)\IronPython 2.7\IronPython.dll ;

• ajoutez une référence au Microsoft.Scripting.dll situé dans C:\Program Files (x86)\IronPython 2.7\Platforms\Net40\Microsoft.Scripting.dll ;

• incluez les instructions IronPython.Hosting et Microsoft.Scripting.Hosting using dans votre classe ;

• ajoutez un constructeur privé vide pour empêcher l’ajout d’un nœud supplémentaire à la bibliothèque Dynamo avec votre package ;

• créez une méthode qui prend une seule chaîne comme paramètre d’entrée ;

• dans cette méthode, nous allons instancier un nouveau moteur Python et créer une portée de script vide. Vous pouvez imaginer cette portée comme les variables globales dans une instance de l’interpréteur Python ;

• appelez ensuite Execute sur le moteur en passant la chaîne d’entrée et la portée comme paramètres ;

• enfin, récupérez et renvoyez les résultats du script en appelant GetVariable sur la portée et en transmettant le nom de la variable de votre script Python qui contient la valeur que vous essayez de renvoyer (Voir l’exemple ci-dessous pour plus de détails).

Le code suivant fournit un exemple pour l’étape mentionnée ci-dessus. La génération de la solution entraîne la création d’un nouveau .dll situé dans le dossier bin de notre projet. Ce .dll peut désormais être importé dans Dynamo en tant que composant d’un package ou en accédant à File < Import Library...

Sorties multiples

L’une des limites des nœuds Python standard est qu’ils n’ont qu’un seul port de sortie. Si nous souhaitons renvoyer plusieurs objets, nous devons construire une liste et récupérer chaque objet à l’intérieur. Si nous modifions l’exemple ci-dessus pour qu’il renvoie un dictionnaire, nous pouvons ajouter autant de ports de sortie que nous le souhaitons. Reportez-vous à la section Renvoyer plusieurs valeurs dans Aller plus loin avec Zero-Touch pour plus de détails sur les dictionnaires.

Ce nœud permet de renvoyer le volume du cuboïde et son centre de gravité.

Modifions l’exemple précédent en procédant comme suit :

• ajoutez une référence DynamoServices.dll du gestionnaire de package NuGet ;

• en plus des assemblages précédents, incluez System.Collections.Generic et Autodesk.DesignScript.Runtime ;

• modifiez le type de retour de notre méthode pour qu’elle renvoie un dictionnaire qui contiendra nos résultats ;

• chaque sortie doit être extraite individuellement de la portée (il est conseillé de configurer une boucle simple pour des ensembles de sorties plus importants).

Nous avons également ajouté une variable de sortie supplémentaire (output2) à l’exemple de script Python. N’oubliez pas que ces variables peuvent utiliser n’importe quelle convention de dénomination légale de Python. La sortie a été utilisée uniquement pour des raisons de clarté dans cet exemple.

Introduction

Cette section contient des informations sur les problèmes que vous pouvez rencontrer lors de la migration de vos graphiques, modules et bibliothèques vers Dynamo 3.x.

Dynamo 3.0 est une version majeure et certaines API ont été modifiées ou supprimées. Le changement le plus important qui est susceptible de vous affecter en tant que développeur ou utilisateur de Dynamo 3.x est le passage à .NET8.

Dotnet/.NET est le runtime qui alimente le langage C# dans lequel Dynamo est écrit. Nous avons mis à jour cette version de runtime vers une version plus récente, ainsi que le reste de l'écosystème Autodesk.

Pour en savoir plus, consultez .

Compatibilité des modules

Utilisation des modules Dynamo 2.x dans Dynamo 3.x

Comme Dynamo 3.x s'exécute désormais sur le runtime .NET8, les modules qui ont été créés pour Dynamo 2.x (à l'aide de .NET48) sont susceptibles de ne pas fonctionner dans Dynamo 3.x. Lorsque vous tentez de télécharger un module dans Dynamo 3.x qui a été publié à partir d'une version de Dynamo antérieure à la version 3.0, vous recevez un avertissement vous indiquant que le module provient d'une version antérieure de Dynamo.

Cela ne signifie pas que le module ne fonctionnera pas. Il s'agit simplement d'un avertissement indiquant que des problèmes de compatibilité peuvent survenir. En général, il est conseillé de vérifier si une version plus récente a été spécialement conçue pour Dynamo 3.x.

Vous pouvez également remarquer ce type d'avertissement dans vos fichiers journaux Dynamo au moment du chargement du module. Si tout fonctionne correctement, vous pouvez l'ignorer.

Utilisation des modules Dynamo 3.x dans Dynamo 2.x

Il est très peu probable qu'un module créé pour Dynamo 3.x (à l'aide de .Net8) fonctionne sur Dynamo 2.x. Un avertissement s'affiche également lors du téléchargement de modules créés pour des versions plus récentes de Dynamo lorsque vous utilisez une version antérieure.

Introduction :

Dynamo 2.0 est une version majeure et certaines API ont été modifiées ou supprimées. L’un des changements les plus importants qui affectera les auteurs de nœuds et de packages est le passage au format de fichier JSON.

Dans la plupart des cas, les auteurs de nœuds Zero-Touch n’auront que peu ou pas de travail à faire pour que leurs packages fonctionnent dans la version 2.0.

Les nœuds d’interface utilisateur et les nœuds qui dérivent directement de NodeModel nécessiteront plus de travail pour fonctionner dans la version 2.x.

Les auteurs d’extensions peuvent également avoir des changements potentiels à faire selon la quantité d’API de Dynamo Core qu’ils utilisent dans leurs extensions.

Règles générales relatives aux packages :

• n’intégrez pas les fichiers .dll de Dynamo ou de Dynamo Revit dans votre package. Ces fichiers .dll seront déjà chargés par Dynamo. Si vous intégrez une version différente de celle que l’utilisateur a chargée (p. ex. vous distribuez sur Dynamo Core 1.3 mais l’utilisateur exécute votre package sur Dynamo 2.0), des bogues d’exécution inattendus se produiront. Cela inclut les fichiers .dll tels que DynamoCore.dll, DynamoServices.dll, DSCodeNodes.dll, ProtoGeometry.dll ;

• évitez d’intégrer et de distribuer des newtonsoft.json.net avec votre package si vous pouvez l’éviter. Ce fichier .dll sera également chargé par Dynamo 2.x. Le même problème que ci-dessus peut se produire ;

• évitez d’intégrer et de distribuer des CEFSharp avec votre package si vous pouvez l’éviter. Ce fichier .dll sera également chargé par Dynamo 2.x. Le même problème que ci-dessus peut se produire ;

• de manière générale, évitez de partager des dépendances avec Dynamo ou Revit si vous avez besoin de contrôler la version de cette dépendance.

Problèmes courants :

1) Lors de l’ouverture d’un graphique, certains nœuds ont plusieurs ports portant le même nom, mais le graphique semble correct lors de l’enregistrement. Ce problème peut avoir plusieurs causes.

La cause principale est que le nœud a été créé à l’aide d’un constructeur qui a recréé les ports. Au lieu de cela, il aurait fallu utiliser un constructeur capable de charger les ports. Ces constructeurs sont généralement marqués [JsonConstructor]. Voir les exemples ci-dessous

Cela peut se produire pour les raisons suivantes :

• il n’y avait tout simplement pas de [JsonConstructor] correspondant, ou il n’a pas été transmis par les fichiers Inports et Outports du fichier JSON .dyn ;

• deux versions de JSON.net ont été chargées simultanément dans le même processus, ce qui a entraîné une erreur au niveau de l’exécution .net, de sorte que l’attribut [JsonConstructor] n’a pas pu être utilisé correctement pour marquer le constructeur ;

• une version de DynamoServices.dll différente de la version actuelle de Dynamo a été incluse dans le package et provoque l’échec de l’exécution .net à identifier l’attribut [MultiReturn], de sorte que les nœuds Zero-Touch marqués avec divers attributs ne pourront pas être appliqués. Il se peut qu’un nœud renvoie une seule sortie de dictionnaire au lieu de plusieurs ports.

2) Des nœuds sont complètement absents lors du chargement du graphique avec des erreurs dans la console.

• Cela peut se produire si votre désérialisation a échoué pour une raison quelconque. Il est recommandé de ne sérialiser que les propriétés dont vous avez besoin. Nous pouvons utiliser [JsonIgnore] sur les propriétés complexes que vous n’avez pas besoin de charger ou d’enregistrer pour les ignorer. Il s’agit de propriétés telles que function pointer, delegate, action, ou event etc. Elles ne doivent pas être sérialisées car elles échoueront généralement à la désérialisation et provoqueront une erreur d’exécution.

Mise à niveau détaillée :

Nœuds personnalisés 1.3 - > 2.0

Problèmes connus :

• les commentaires seront transformés en commentaires de bloc au lieu de commentaires de ligne ;

• les noms de type abrégés seront remplacés par des noms complets. Par exemple, si vous n’avez pas spécifié de type lorsque vous chargez à nouveau le nœud personnalisé, var[]..[] s’affiche, car il s’agit du type par défaut.

Nœuds Zero-Touch 1.3 -> 2.0

• Dans Dynamo 2.0, les types Liste et Dictionnaire ont été divisés et la syntaxe pour créer des listes et des dictionnaires a été modifiée. Les listes sont initialisées à l’aide de [] tandis que les dictionnaires utilisent {}. Si vous utilisiez auparavant l’attribut DefaultArgument pour marquer les paramètres de vos nœuds Zero-Touch et utilisiez la syntaxe de liste par défaut pour une liste spécifique telle que someFunc([DefaultArgument("{0,1,2}")]), ceci ne sera plus valable et vous devrez modifier l’extrait de code DesignScript pour utiliser la nouvelle syntaxe d’initialisation pour les listes.

• Comme indiqué ci-dessus, ne distribuez pas de fichiers .dll Dynamo avec vos packages. (DynamoCore, DynamoServices, etc.).

Nœuds de modèle de nœud 1.3 -> 2.0

Les nœuds de modèle de nœud nécessitent le plus de travail pour passer à Dynamo 2.x. De manière générale, vous devez implémenter des constructeurs qui seront utilisés uniquement pour charger vos nœuds à partir de json, en plus des constructeurs nodeModel standard utilisés pour instancier de nouvelles instances de vos types de nœud. Pour les différencier, vous devez marquer les constructeurs de chargement à l’aide de l’attribut [JsonConstructor] de newtonsoft.Json.net.

Constructeurs JSON

La modification la plus courante requise pour mettre à jour les nœuds dérivés de la classe de base NodeModel (ou d’autres classes de base Dynamo Core, par exemple DSDropDownBase) est la nécessité d’ajouter un constructeur JSON à votre classe.

Votre constructeur original sans paramètre gérera toujours l’initialisation d’un nouveau nœud créé au sein de Dynamo (via la bibliothèque par exemple). Le constructeur JSON est requis pour initialiser un nœud désérialisé (chargé) à partir d’un fichier .dyn ou .dyf enregistré.

Le constructeur JSON diffère du constructeur de base, car il possède des paramètres PortModel pour les inPorts et les outPorts, fournis par la logique de chargement JSON. L’appel pour enregistrer les ports pour le nœud n’est pas requis ici, car les données existent dans le fichier .dyn. Voici un exemple de constructeur JSON :

using Newtonsoft.Json; //New dependency for Json

………

[JsonConstructor] //Attribute required to identity the Json constructor

//Minimum constructor implementation. Note that the base method invocation must also be present.

FooNode(IEnumerable<PortModel> inPorts, IEnumerable<PortModel> outPorts) : base(inPorts, outPorts) { }

Cette syntaxe :base(Inports,outPorts){} appelle le constructeur de base nodeModel et lui transmet les ports désérialisés.

Il n’est pas nécessaire de répéter dans ce constructeur toute logique spéciale qui existait dans le constructeur de la classe et qui impliquait l’initialisation de données spécifiques sérialisées dans le fichier .dyn (par exemple la définition de l’enregistrement du port, la stratégie de combinaison, etc.), car ces valeurs peuvent être lues à partir du JSON.

C’est la principale différence entre le constructeur JSON et les constructeurs non-JSON pour vos nodeModels. Les constructeurs JSON sont appelés lors du chargement à partir d’un fichier et les données chargées sont transmises. D’autres éléments de la logique utilisateur doivent cependant être dupliqués dans le constructeur JSON (par exemple, l’initialisation des gestionnaires d’événements pour le nœud ou l’association).

Propriétés publiques et sérialisation

[JsonProperty(PropertyName = "InputValue")]

public DSColor DsColor {...

Convertisseurs :

Remarque Si vous créez votre propre classe de convertisseur JSON.net, Dynamo ne dispose pas actuellement d’un mécanisme qui vous permet de l’injecter dans les méthodes de chargement et d’enregistrement. Ainsi, même si vous marquez votre classe avec l’attribut [JsonConverter], elle ne peut pas être utilisée, à la place vous pouvez appeler votre convertisseur directement dans votre setter ou getter. //À FAIRE : avoir la confirmation de cette limitation. Toute preuve est la bienvenue.

[JsonProperty("MeasurementType"), JsonConverter(typeof(StringEnumConverter))]

public ConversionMetricUnit SelectedMetricConversion{...

Ignorer les propriétés

Annuler/Rétablir

Comme indiqué ci-dessus, les méthodes SerializeCore et DeserializeCore étaient utilisées dans le passé pour enregistrer et charger des nœuds dans le fichier xml .dyn. En outre, elles étaient également utilisées pour enregistrer et charger l’état des nœuds pour annuler/rétabliret le sont toujours ! Si vous souhaitez mettre en œuvre une fonctionnalité complexe Annuler/Rétablir pour votre nœud de l’interface utilisateur nodeModel, vous devrez mettre en œuvre ces méthodes et sérialiser dans l’objet document XML fourni en tant que paramètre de ces méthodes. Il s’agit d’un cas d’utilisation rare, sauf pour les nœuds complexes de l’interface utilisateur.

API des ports d’entrée et de sortie

L’enregistrement du port dans le constructeur du nœud est un phénomène courant dans les nœuds nodeModel concernés par les modifications de l’API 2.0. Si vous avez déjà regardé des exemples dans le dépôt Dynamo ou DynamoSamples, il est possible que vous ayez utilisé les méthodes InPortData.Add() ou OutPortData.Add(). Auparavant, dans l’API Dynamo, les propriétés publiques InPortData et OutPortData étaient marquées comme étant obsolètes. Dans la version 2.0, ces propriétés ont été supprimées. Les développeurs doivent maintenant utiliser les méthodes InPorts.Add() et OutPorts.Add(). En outre, ces deux méthodes Add() ont des signatures légèrement différentes :

InPortData.Add(new PortData("Port Name", "Port Description")); //Old version valid in 1.3 but now deprecated

comparé à

InPorts.Add(new PortModel(PortType.Input, this, new PortData("Port Name", "Port Description"))); //Recommended 2.0

Exemples :

Nous allons voir comment mettre à jour un nœud d’interface utilisateur 1.3 vers Dynamo 2.x.

Pour charger et enregistrer correctement cette classe nodeModel dans la version 2.0, il suffit d’ajouter un jsonConstructor pour gérer le chargement des ports. Nous passons simplement les ports au constructeur de base et cette implémentation est vide.

Remarque : n’appelez pas RegisterPorts() ou une variante de ce paramètre dans votre JsonConstructor. Cela utilisera les attributs des paramètres d’entrée et de sortie de votre classe de nœuds pour construire de nouveaux ports ! Ce n’est pas ce que nous souhaitons, puisque nous voulons utiliser les ports chargés qui sont passés au constructeur.

Voici un constructeur plus complexe pour un nœud d’interface utilisateur :

Lorsque nous ajoutons un constructeur JSON pour charger ce nœud à partir d’un fichier, nous devons recréer une partie de cette logique, mais notez que nous n’incluons pas le code qui crée les ports, définit la combinaison ou les valeurs par défaut des propriétés que nous pouvons charger à partir du fichier.

Notez que les autres propriétés publiques qui ont été sérialisées dans le JSON comme ButtonText et WindowText ne devront pas être ajoutées en tant que paramètres explicites au constructeur. Elles sont définies automatiquement par JSON.net en utilisant les setters pour ces propriétés.

Après avoir appris à créer un projet Zero-Touch, nous pouvons approfondir les spécificités de la création d’un nœud en parcourant l’exemple ZeroTouchEssentials sur Dynamo Github.

De nombreux nœuds standard de Dynamo sont essentiellement des nœuds Zero-Touch, comme la plupart des nœuds Math, Color et DateTime ci-dessus.

Pour commencer, téléchargez le projet ZeroTouchEssentials à partir de l’emplacement suivant :

Dans Visual Studio, ouvrez le fichier solution ZeroTouchEssentials.sln et générez la solution.

Le fichier ZeroTouchEssentials.cs contient toutes les méthodes que vous allez importer dans Dynamo.

Ouvrez Dynamo et importez le ZeroTouchEssentials.dll pour obtenir les nœuds que vous allez référencer dans les exemples suivants.

Valeur d’entrée par défaut

• Définissez les paramètres de la méthode à une valeur par défaut : inputNumber = 2.0

1. La valeur par défaut s’affiche lorsque vous passez le curseur sur le port d’entrée du nœud.

Renvoyer plusieurs valeurs

Le renvoi de plusieurs valeurs est un peu plus complexe que la création de plusieurs entrées et devra être renvoyé à l’aide d’un dictionnaire. Les entrées du dictionnaire deviennent des ports sur le côté sortie du nœud. Les ports de retour multiples peuvent être créés de la manière suivante :

• ajoutez using System.Collections.Generic; pour utiliser Dictionary<> ;

• ajoutez using Autodesk.DesignScript.Runtime; pour utiliser l’attribut MultiReturn. Cela fait référence à « DynamoServices.dll » du package DynamoServices NuGet ;

• ajoutez l’attribut [MultiReturn(new[] { "string1", "string2", ... more strings here })] à la méthode. Les chaînes font référence aux clés du dictionnaire et deviendront les noms des ports de sortie ;

• renvoyez un Dictionary<> de la fonction dont les clés correspondent aux noms des paramètres dans l’attribut : return new Dictionary<string, object>.

Un nœud qui renvoie plusieurs sorties.

1. Notez que deux ports de sortie sont désormais nommés en fonction des chaînes que nous avons saisies pour les clés du dictionnaire.

Documentation, info-bulles et recherche

Il est recommandé d’ajouter de la documentation aux nœuds Dynamo pour décrire la fonction du nœud, les entrées, les sorties, les balises de recherche, etc. Cela se fait par le biais de balises de documentation XML. Pour créer de la documentation XML, procédez de la manière suivante :

• tout texte de commentaire précédé de trois barres obliques est considéré comme de la documentation ;

  • par exemple : /// Documentation text and XML goes here

• après les trois barres obliques, créez des balises XML au-dessus des méthodes que Dynamo lira lors de l’importation du fichier .dll ;

  • par exemple : /// <summary>...</summary>

• activez la documentation XML dans Visual Studio en sélectionnant Project > Project Properties > Build et en cochant la case XML documentation file.

1. Visual Studio générera un fichier XML à l’emplacement spécifié.

Les types de balises sont les suivants :

• /// <summary>...</summary> est la documentation principale de votre nœud et apparaît sous forme d’infobulle au-dessus de votre nœud dans la barre latérale de recherche gauche ;

• /// <param name="inputName">...</param> créera une documentation pour des paramètres d’entrée spécifiques ;

• /// <returns>...</returns> créera une documentation pour un paramètre de sortie ;

• /// <returns name = "outputName">...</returns> créera une documentation pour plusieurs paramètres de sortie ;

• /// <search>...</search> fera correspondre votre nœud à des résultats de recherche basés sur une liste séparée par des virgules. Par exemple, si nous créons un nœud qui subdivise un maillage, nous pouvons ajouter des balises telles que « maillage », « subdivision » et « catmull-clark ».

L’exemple suivant présente un nœud avec des descriptions d’entrée et de sortie, ainsi qu’un résumé qui s’affichera dans la bibliothèque.

Notez que le code de cet exemple de nœud contient :

1. un résumé du nœud ;

2. une description d’entrée ;

3. une description de sortie.

Objets

Dynamo ne possède pas de mot-clé new, les objets doivent donc être construits à l’aide de méthodes de construction statiques. Les objets sont construits de la façon suivante :

• rendez le constructeur interne internal ZeroTouchEssentials() à moins de devoir le faire autrement ;

• construisez l’objet avec une méthode statique telle que public static ZeroTouchEssentials ByTwoDoubles(a, b).

Remarque : Dynamo utilise le préfixe « By » pour indiquer qu’une méthode statique est un constructeur, et bien que cela soit optionnel, l’utilisation de « By » aidera votre bibliothèque à mieux s’adapter au style existant de Dynamo.

Une fois que le .dll ZeroTouchEssentials a été importé, un nœud ZeroTouchEssentials sera présent dans la bibliothèque. Cet objet peut être créé en utilisant le nœud ByTwoDoubles.

Utiliser des types de géométrie Dynamo

Les bibliothèques Dynamo peuvent utiliser les types de géométrie Dynamo en entrée et créer de nouvelles géométries en sortie. Les types de géométrie sont créés de la manière suivante :

• Référencez « ProtoGeometry.dll » dans le projet en incluant using Autodesk.DesignScript.Geometry; au début de votre fichier C# et en ajoutant le package NuGet ZeroTouchLibrary au projet.

• Important : gérez les ressources de géométrie qui ne sont pas renvoyées par vos fonctions. Reportez-vous à la section Instructions using/dispose ci-dessous.

Remarque : les objets de géométrie Dynamo sont utilisés comme tout autre objet transmis aux fonctions.

Un nœud qui obtient la longueur d’une courbe et la double.

1. Ce nœud accepte un type de géométrie Courbe comme entrée.

Instructions using/dispose

Les ressources de géométrie qui ne sont pas renvoyées par les fonctions devront être gérées manuellement à moins que vous n’utilisiez Dynamo version 2.5 ou ultérieure. Dans Dynamo 2.5 et versions ultérieures, les ressources de géométrie sont gérées en interne par le système. Toutefois, vous devrez peut-être supprimer la géométrie manuellement si vous avez un cas d’utilisation complexe ou si vous devez réduire la mémoire à un moment précis. Le moteur Dynamo traitera toutes les ressources de géométrie qui sont renvoyées par des fonctions. Les ressources de géométrie qui ne sont pas renvoyées peuvent être traitées manuellement de l’une des manières suivantes :

• Avec une instruction using :

• Avec les appels dispose manuels :

Migrations

Lors de la publication d’une nouvelle version d’une bibliothèque, les noms des nœuds peuvent changer. Les changements de nom peuvent être spécifiés dans un fichier migrations afin que les graphiques générés sur des versions antérieures d’une bibliothèque continuent à fonctionner correctement lorsqu’une mise à jour est effectuée. Les migrations sont implémentées de la manière suivante :

• créez un fichier .xml dans le même dossier que le .dll au format suivant : « BaseDLLName ».Migrations.xml ;

• dans le .xml, créez un seul élément <migrations>...</migrations> ;

• dans l’élément migrations, créez <priorNameHint>...</priorNameHint> éléments pour chaque changement de nom ;

• pour chaque changement de nom, fournissez un élément <oldName>...</oldName> et <newName>...</newName>.

1. Cliquez avec le bouton droit de la souris et sélectionnez Add > New Item

2. Choisissez XML File

3. Pour ce projet, nous nommerons le fichier migrations ZeroTouchEssentials.Migrations.xml

Cet exemple de code indique à Dynamo que tout nœud nommé GetClosestPoint est désormais nommé ClosestPointTo.

Génériques

Zero-Touch ne prend pas en charge l’utilisation de génériques pour l’instant. Ils peuvent être utilisés, mais pas dans le code importé directement lorsque le type n’est pas défini. Les méthodes, propriétés ou classes génériques qui ne possèdent pas le type défini ne peuvent pas être exposées.

Dans l’exemple ci-dessous, un nœud Zero-Touch de type T ne sera pas importé. Si le reste de la bibliothèque est importé dans Dynamo, il y aura des exceptions de type manquant.

L’utilisation d’un type générique avec le type défini dans cet exemple est importée dans Dynamo.

Les extensions sont un outil de développement puissant dans l’écosystème Dynamo. Elles permettent aux développeurs de créer des fonctionnalités personnalisées basées sur les interactions et la logique de Dynamo. Les extensions peuvent être divisées en deux catégories principales : les extensions et les extensions de vue. Comme son nom l’indique, le cadre d’extension de vue vous permet d’étendre l’interface utilisateur Dynamo en enregistrant des éléments de menu personnalisés. Les extensions classiques fonctionnent de manière très similaire, à l’exception de l’interface utilisateur. Par exemple, nous pourrions générer une extension qui enregistre des informations spécifiques dans la console Dynamo. Ce scénario ne nécessite pas d’interface utilisateur personnalisée et pourrait donc être réalisé à l’aide d’une extension.

Étude de cas sur les extensions

En suivant l’exemple SampleViewExtension du dépôt DynamoSamples de Github, nous allons parcourir les étapes nécessaires à la création d’une simple fenêtre sans modèle qui affiche les nœuds actifs du graphique en temps réel. Une extension de vue nécessite la création d’une interface utilisateur pour la fenêtre et l’association de valeurs à un modèle de vue.

1. La fenêtre d’extension de vue a été développée en suivant l’exemple SampleViewExtension dans le dépôt de Github.

Bien que nous allons générer l’exemple à partir de zéro, vous pouvez également télécharger et générer le dépôt DynamoSamples comme référence.

Cette présentation fait référence au projet nommé SampleViewExtension qui se trouve dans DynamoSamples/src/.

Comment implémenter une extension de vue

Une extension de vue comporte trois parties essentielles :

• un assemblage contenant une classe qui implémente IViewExtension ainsi qu’une classe qui crée un modèle de vue ;

• un fichier .xml qui indique à Dynamo où il doit chercher cet assemblage lors de l’exécution, et le type d’extension ;

• un fichier .xaml qui lie les données à l’affichage graphique et détermine l’apparence de la fenêtre.

1. Créer la structure du projet

Commencez par créer un projet Class Library nommé SampleViewExtension.

1. Créez un projet en sélectionnant File > New > Project

2. Sélectionnez Class Library

3. Nommez le projet SampleViewExtension

4. Sélectionnez Ok

Dans ce projet, nous aurons besoin de deux classes. Une classe implémentera IViewExtension et une autre qui implémentera NotificationObject. IViewExtension contiendra toutes les informations sur la façon dont l’extension sera déployée, chargée, référencée et supprimée. NotificationObject fournira des notifications pour les modifications dans Dynamo et IDisposable. Lorsqu’un changement se produit, le compte sera mis à jour en conséquence.

1. Un fichier de classe nommé SampleViewExtension.cs qui implémentera IViewExtension

2. Un fichier de classe nommé SampleWindowViewMode.cs qui implémentera NotificationObject

Pour utiliser IViewExtension, nous aurons besoin du package NuGet WpfUILibrary. L’installation de ce package installera automatiquement les packages Core, Services et ZeroTouchLibrary.

1. Sélectionnez la bibliothèque WpfUILibrary

2. Sélectionnez Install pour installer tous les packages dépendants

2. Implémenter la classe IViewExtension

Dans la classe IViewExtension, nous allons déterminer les actions qui se produisent au démarrage de Dynamo, au chargement de l’extension et à l’arrêt de Dynamo. Dans le fichier de classe SampleViewExtension.cs, ajoutez le code suivant :

La classe SampleViewExtension crée un élément de menu cliquable pour ouvrir la fenêtre et le relie au modèle de vue et à la fenêtre.

• public class SampleViewExtension : IViewExtension SampleViewExtension hérite de l’interface IViewExtension et fournit tout ce dont nous avons besoin pour créer l’élément de menu.

• sampleMenuItem = new MenuItem { Header = "Show View Extension Sample Window" }; crée un élément MenuItem et l’ajoute au menu View.

1. L’élément de menu

• sampleMenuItem.Click += (sender, args) déclenche un événement qui ouvre une nouvelle fenêtre lorsque vous cliquez sur l’élément de menu

• MainGrid = { DataContext = viewModel } définit le contexte de données pour la grille principale de la fenêtre, en se référant à Main Grid dans le fichier .xaml que nous allons créer

• Owner = p.DynamoWindow définit le propriétaire de la fenêtre contextuelle sur Dynamo. Cela signifie que la nouvelle fenêtre est dépendante de Dynamo, de sorte que les actions telles que la réduction, l’agrandissement et la restauration de Dynamo entraîneront le même comportement dans la nouvelle fenêtre

• window.Show(); affiche la fenêtre dans laquelle les propriétés de fenêtre supplémentaires ont été définies

3. Implémentation du modèle de vue

Maintenant que nous avons établi certains des paramètres de base de la fenêtre, nous allons ajouter la logique de réponse aux différents événements liés à Dynamo et indiquer à l’interface utilisateur de se mettre à jour en fonction de ces événements. Copiez le code suivant dans le fichier de classe SampleWindowViewModel.cs :

Cette implémentation de la classe de modèle de vue écoute le CurrentWorkspaceModel et déclenche un événement lorsqu’un nœud est ajouté ou supprimé de l’espace de travail. Cela déclenche un changement de propriété qui signale à l’interface utilisateur ou aux éléments liés que les données ont changé et qu’elles doivent être mises à jour. Le getter ActiveNodeTypes est appelé, ce qui appelle en interne une fonction d’assistant supplémentaire getNodeTypes(). Cette fonction parcourt tous les nœuds actifs de la zone de dessin, remplit une chaîne contenant les noms de ces nœuds et renvoie cette chaîne à notre liaison dans le fichier .xaml pour qu’elle soit affichée dans notre fenêtre contextuelle.

Une fois la logique principale de l’extension définie, vous allez maintenant spécifier les détails d’apparence de la fenêtre avec un fichier .xaml. Il suffit d’une simple fenêtre qui affiche la chaîne via la liaison de propriété ActiveNodeTypes dans le TextBlock Text.

1. Cliquez avec le bouton droit de la souris sur le projet et choisissez Add > New Item...

2. Sélectionnez le modèle de contrôle utilisateur que vous allez modifier pour créer une fenêtre

3. Nommez le nouveau fichier SampleWindow.xaml

4. Sélectionnez Add

Dans le code de la fenêtre .xaml, vous devez lier SelectedNodesText à un bloc de texte. Ajoutez le code suivant à SampleWindow.xaml :

• Text="{Binding ActiveNodeTypes}" se lie à la valeur de propriété de ActiveNodeTypes dans SampleWindowViewModel.cs à la valeur de TextBlock Text dans la fenêtre.

Nous allons maintenant initialiser la fenêtre d’exemple dans le fichier de sauvegarde .xaml C# SampleWindow.xaml.cs. Ajoutez le code suivant à SampleWindow.xaml :

L’extension de vue est maintenant prête à être créée et ajoutée à Dynamo. Dynamo requiert un fichier xml pour enregistrer la sortie .dll en tant qu’extension.

1. Cliquez avec le bouton droit de la souris sur le projet et choisissez Add > New Item...

2. Sélectionner un fichier XML

3. Nommez le fichier SampleViewExtension_ViewExtensionDefinition.xml

4. Sélectionnez Add

• Le nom du fichier suit la norme Dynamo pour référencer un ensemble d’extension de la manière suivante : "extensionName"_ViewExtensionDefinition.xml

Dans le fichier xml, ajoutez le code suivant pour indiquer à Dynamo où rechercher l’assemblage d’extension :

• Dans cet exemple, nous avons créé l’assemblage dans le dossier par défaut du projet Visual Studio. Remplacez la cible <AssemblyPath>...</AssemblyPath> par l’emplacement de l’assemblage.

La dernière étape consiste à copier le fichier SampleViewExtension_ViewExtensionDefinition.xml dans le dossier des extensions de vue de Dynamo situé dans le répertoire d’installation de Dynamo Core C:\Program Files\Dynamo\Dynamo Core\1.3\viewExtensions. Il est important de noter qu’il existe des dossiers distincts pour extensions et viewExtensions. Placer le fichier xml dans un dossier incorrect peut entraîner un échec du chargement au moment de l’exécution.

1. Le fichier .xml que nous avons copié dans le dossier des extensions de vue de Dynamo

Il s’agit d’une introduction sommaire aux extensions de vues. Pour une étude de cas plus sophistiquée, consultez le package DynaShape, un projet open source sur Github. Le package utilise une extension de vue qui permet de modifier en direct la vue du modèle Dynamo.

Les nœuds basés sur NodeModel offrent beaucoup plus de flexibilité et de puissance que les nœuds Zero-Touch. Dans cet exemple, nous ferons passer le nœud de grille Zero-Touch au niveau supérieur en ajoutant un curseur intégré qui randomise la taille du rectangle.

Le curseur met à l’échelle les cellules en fonction de leur taille, de sorte que l’utilisateur n’a pas besoin de fournir un curseur avec la plage correcte.

Modèle vue-vue modèle

À un haut niveau, établir une relation modèle-vue dans Dynamo se fait en deux temps :

• Une classe NodeModel pour établir la logique de base du nœud (le « modèle »)

• Une classe INodeViewCustomization pour personnaliser la façon dont le NodeModel est affiché (la « vue »)

Les objets NodeModel ont déjà une vue-modèle associée (NodeViewModel), nous pouvons donc nous concentrer uniquement sur le modèle et la vue pour l’interface utilisateur personnalisée.

Comment implémenter NodeModel

Les nœuds NodeModel présentent plusieurs différences significatives par rapport aux nœuds Zero-Touch que nous aborderons dans cet exemple. Avant de passer à la personnalisation de l’interface utilisateur, commençons par générer la logique NodeModel.

1. Créer la structure du projet :

Un nœud NodeModel ne peut appeler que des fonctions, nous devons donc séparer le NodeModel et les fonctions dans des bibliothèques différentes. La façon standard de procéder pour les packages Dynamo est de créer des projets distincts pour chacun d’entre eux. Commencez par créer une nouvelle solution pour englober les projets.

1. Sélectionnez File > New > Project

2. Sélectionnez Other Project Types pour afficher l’option Solution

3. Sélectionnez Blank Solution

4. Nommez la solution CustomNodeModel

5. Sélectionnez Ok

Créez deux projets de bibliothèque de classes C# dans la solution : un pour les fonctions et un pour la mise en œuvre de l’interface NodeModel.

1. Cliquez avec le bouton droit de la souris sur la solution et sélectionnez Add > New Project

2. Choisissez une bibliothèque de classe

3. Nommez-le CustomNodeModel

4. Cliquez sur Ok

5. Répétez l’opération pour ajouter un autre projet nommé CustomNodeModelFunctions

Ensuite, nous devons renommer les bibliothèques de classes qui ont été créées automatiquement et en ajouter une au projet CustomNodeModel. La classe GridNodeModel implémente la classe abstraite NodeModel, GridNodeView est utilisée pour personnaliser la vue et GridFunction contient toutes les fonctions que nous devons appeler.

1. Ajoutez une autre classe en cliquant avec le bouton droit de la souris sur le projet CustomNodeModel, en sélectionnant Add > New Item... et en choisissant Class

2. Dans le projet CustomNodeModel, nous avons besoin de GridNodeModel.cs et de GridNodeView.cs

3. Dans le projet CustomNodeModelFunction, nous avons besoin d’une classe GridFunctions.cs

Avant d’ajouter du code aux classes, ajoutez les packages nécessaires pour ce projet. CustomNodeModel aura besoin de ZeroTouchLibrary et de WpfUILibrary, et CustomNodeModelFunction n’aura besoin que de ZeroTouchLibrary. La bibliothèque WpfUILibrary sera utilisée dans la personnalisation de l’interface utilisateur que nous effectuerons ultérieurement, et la bibliothèque ZeroTouchLibrary sera utilisée pour la création de géométries. Les packages peuvent être ajoutés individuellement pour les projets. Comme ces packages ont des dépendances, Core et DynamoServices seront automatiquement installés.

1. Cliquez avec le bouton droit de la souris sur un projet et choisissez Manage NuGet Packages

2. Installez uniquement les packages requis pour ce projet

Visual Studio copie les packages NuGet référencés dans le répertoire de génération. Cette valeur peut être définie sur False pour éviter que le package ne contienne des fichiers inutiles.

1. Sélectionnez les packages Dynamo NuGet

2. Définissez Copy Local sur False

2. Hériter de la classe NodeModel

Comme indiqué précédemment, l’aspect principal qui différencie un nœud NodeModel d’un nœud Zero-Touch est son implémentation de la classe NodeModel. Un nœud NodeModel a besoin de plusieurs fonctions de cette classe, et nous pouvons les obtenir en ajoutant :NodeModel après le nom de la classe.

Copiez le code suivant dans GridNodeModel.cs.

Cela diffère des nœuds Zero-Touch. Voyons ce que fait chaque partie.

• Spécifiez les attributs de nœud tels que le nom, la catégorie, les noms InPort/OutPort, les types InPort/OutPort et les descriptions.

• public class GridNodeModel : NodeModel est une classe qui hérite de la classe NodeModel de Dynamo.Graph.Nodes.

• public GridNodeModel() { RegisterAllPorts(); } est un constructeur qui enregistre les entrées et les sorties du nœud.

• BuildOutputAst() renvoie une structure ASA (Arbre de la syntaxe abstraite), qui est requise pour renvoyer des données à partir d’un nœud NodeModel.

• AstFactory.BuildFunctionCall() appelle la fonction RectangularGrid à partir de GridFunctions.cs.

• new Func<int, int, double, List<Rectangle>>(GridFunction.RectangularGrid) spécifie la fonction et ses paramètres.

• new List<AssociativeNode> { inputAstNodes[0], inputAstNodes[1], sliderValue }); mappe les entrées des nœuds aux paramètres des fonctions.

• AstFactory.BuildNullNode() génère un nœud nul si les ports d’entrée ne sont pas connectés. Cela permet d’éviter l’affichage d’un avertissement sur le nœud.

• RaisePropertyChanged("SliderValue") notifie l’interface utilisateur lorsque la valeur du curseur change.

• var sliderValue = AstFactory.BuildDoubleNode(SliderValue) génère un nœud dans l’ASA qui représente la valeur du curseur.

• Modifiez une entrée pour la variable sliderValue dans la variable functionCall new List<AssociativeNode> { inputAstNodes[0], sliderValue });.

3. Appeler une fonction

Le projet CustomNodeModelFunction sera créé dans un assemblage séparé de CustomNodeModel afin qu’il puisse être appelé.

Copiez le code suivant dans GridFunction.cs.

Cette classe de fonction est très similaire à l’étude de cas Zero-Touch : nœud grille, à une différence près :

• [IsVisibleInDynamoLibrary(false)] empêche Dynamo de « voir » la méthode et la classe suivantes, car la fonction est déjà appelée à partir de CustomNodeModel.

Tout comme nous avons ajouté des références pour les packages NuGet, CustomNodeModel devra faire référence à CustomNodeModelFunction pour appeler la fonction.

L’instruction using pour CustomNodeModel sera inactive jusqu’à ce que nous référencions la fonction

1. Cliquez avec le bouton droit de la souris sur CustomNodeModel et sélectionnez Add > Reference

2. Choisissez Projects > Solution

3. Cochez la case CustomNodeModelFunction

4. Cliquez sur Ok

4. Personnaliser la vue

Pour créer un curseur, nous devons personnaliser l’interface utilisateur en implémentant l’interface INodeViewCustomization.

Copiez le code suivant dans GridNodeView.cs.

• public class CustomNodeModelView : INodeViewCustomization<GridNodeModel> définit les fonctions nécessaires pour personnaliser l’interface utilisateur.

Une fois la structure du projet mise en place, utilisez l’environnement de conception de Visual Studio pour générer un contrôle utilisateur et définir ses paramètres dans un fichier .xaml. Dans la boîte à outils, ajoutez un curseur à <Grid>...</Grid>.

1. Cliquez avec le bouton droit de la souris sur CustomNodeModel et sélectionnez Add > New Item

2. Sélectionnez WPF

3. Nommez le contrôle utilisateur Slider

4. Cliquez sur Add

Copiez le code suivant dans Slider.xaml

• Les paramètres du contrôle du curseur sont définis dans le fichier .xaml. Les attributs Minimum et Maximum définissent la plage numérique de ce curseur.

• Dans <Grid>...</Grid>, nous pouvons placer différents contrôles utilisateur de la boîte à outils de Visual Studio.

Lorsque nous avons créé le fichier Slider.xaml, Visual Studio a automatiquement créé un fichier C# appelé Slider.xaml.cs qui initialise le curseur. Modifiez l’espace de noms dans ce fichier.

• L’espace de noms doit être CustomNodeModel.CustomNodeModel

Le GridNodeModel.cs définit la logique de calcul du curseur.

5. Configurer en tant que package

Avant de générer le projet, la dernière étape consiste à ajouter un fichier pkg.json pour que Dynamo puisse lire le package.

1. Cliquez avec le bouton droit de la souris sur CustomNodeModel et sélectionnez Add > New Item

2. Sélectionnez Web

3. Sélectionnez JSON File

4. Nommez le fichier pkg.json

5. Cliquez sur Add

• Copiez le code suivant dans pkg.json

• "name": détermine le nom du package et de son groupe dans la bibliothèque Dynamo

• "keywords": fournit des termes de recherche pour la bibliothèque Dynamo

• "node_libraries": [] les bibliothèques associées au package

  La dernière étape consiste à générer la solution et à la publier en tant que package Dynamo. Consultez le chapitre Déploiement de package pour savoir comment créer un package local avant de publier en ligne et comment générer un package directement à partir de Visual Studio.

Dynamo repose sur la créativité et l’engagement de sa communauté, et l’équipe Dynamo encourage les contributeurs à explorer les possibilités, à tester les idées et à demander l’avis de la communauté. Bien que l’innovation soit fortement encouragée, les modifications ne seront fusionnées que si elles facilitent l’utilisation de Dynamo et répondent aux instructions définies dans ce document. Les modifications ayant des avantages limités ne seront pas fusionnées.

Attentes relatives aux demandes de tirage

L’équipe Dynamo s’attend à ce que les demandes de tirage suivent ces quelques règles :

• respecter les normes de codage et les normes d’attribution de noms de nœud ;

• intégrer les tests unitaires lors de l’ajout de nouvelles fonctionnalités ;

• lors de la correction d’un bogue, ajouter un test unitaire qui illustre le dysfonctionnement actuel ;

• garder la discussion centrée sur une seule demande. Créez une nouvelle question si un nouveau sujet ou un sujet connexe est abordé.

Quelques indications sur ce qu’il ne faut pas faire :

• nous surprendre avec des demandes de tirage importantes. il est préférable de soumettre une demande et d’entamer une discussion afin que nous puissions nous mettre d’accord sur une direction à prendre avant d’investir beaucoup de temps ;

• faire un commit de code que vous n’avez pas écrit. Si vous trouvez du code que vous pensez pouvoir ajouter à Dynamo, soumettez une demande et lancez une discussion avant de continuer ;

• soumettre des demandes de tirage qui modifient les fichiers ou en-têtes associés aux licences. Si vous pensez qu’il y a un problème avec ces derniers, soumettez une demande et nous nous ferons un plaisir d’en discuter ;

• apporter des ajouts à l’API sans soumettre une demande et sans en discuter d’abord avec nous.

Remplissage du modèle de demande de tirage

Lors de la soumission d’une demande de tirage, utilisez le modèle de demande de tirage par défaut. Avant de soumettre votre demande de tirage, assurez-vous que l’objectif est clairement décrit et que toutes les affirmations suivantes sont exactes :

• le code base est de meilleur qualité après cette demande de tirage ;

• est documenté selon les normes ;

• le niveau de test inclus dans cette demande de tirage est approprié ;

• les éventuelles chaînes de caractères destinées à l’utilisateur sont extraites dans des fichiers *.resx ;

• tous les tests sont réussis grâce à l’intégration continue en libre-service ;

• capture d’écran des modifications apportées à l’interface utilisateur, le cas échéant ;

• les modifications apportées à l’API sont conformes à la procédure de gestion des versions sémantique et sont décrites dans le document Modifications apportées à l’API.

Un réviseur approprié sera affecté à votre demande de tirage par l’équipe Dynamo.

Processus d’examen des demandes de tirage

Une fois la demande soumise, vous pouvez être amené à participer au processus d’examen. Veuillez tenir compte des critères d’examen suivants :

• l’équipe Dynamo se réunit une fois par mois pour examiner les demandes de tirage, de la plus ancienne à la plus récente ;

• si une demande de tirage examinée nécessite des modifications de la part du propriétaire, ce dernier dispose de 30 jours pour y répondre. Si la demande de tirage n’a connu aucune activité lors de la session suivante, elle sera soit fermée par l’équipe, soit, selon son utilité, prise en charge par quelqu’un de l’équipe ;

• les demandes de tirage doivent utiliser le modèle de demande de tirage par défaut de Dynamo ;

• les demandes de tirage pour lesquelles les modèles de demande de tirage de Dynamo ne sont pas entièrement remplis avec toutes les déclarations satisfaites ne seront pas examinées.

Sélection des commits de Dynamo Revit

Étant donné qu’il existe plusieurs versions de Revit sur le marché, il se peut que vous soyez obligé de sélectionner vos modifications dans des branches release spécifiques de DynamoRevit afin que les différentes versions de Revit puissent bénéficier des nouvelles fonctionnalités. Pendant le processus d’examen, les contributeurs seront responsables de la sélection de leurs commits examinés dans les autres branches de DynamoRevit comme spécifié par l’équipe Dynamo.

Si vous cherchez des exemples sur la façon de développer pour Dynamo, consultez les ressources ci-dessous :

Exemples de dépôts

Ces exemples sont des modèles Visual Studio que vous pouvez utiliser pour démarrer votre propre projet :

• ZeroTouchEssentials: modèle pour les nœuds ZeroTouch de base.

  • Renvoie plusieurs sorties : code

  • Utiliser un objet de géométrie natif de Dynamo : code

  • Propriété d’exemple (nœud de requête) : code

• HelloDynamo: modèles pour les nœuds NodeModel de base et la personnalisation des vues.

  • Modèle NodeModel de base : HelloNodeModel.cs

    • Définir les attributs des nœuds (noms des entrées/sorties, descriptions, types) : code

    • Renvoie un nœud nul s’il n’y a pas d’entrées : code

    • Créer un appel de fonction : code

  • Modèle de personnalisation de la vue NodeModel de base : HelloGui.cs, HelloGuiNodeView.cs, Slider.xaml, Slider.xaml.cs

    • Signaler à l’interface utilisateur qu’un élément doit être mis à jour : code

    • Personnaliser le NodeModel : code

    • Définir les attributs de curseur : code

    • Déterminer la logique d’interaction pour le curseur : code

• DynamoSamples: modèles pour ZeroTouch, interface utilisateur personnalisée, tests et extensions de vue.

  • Exemples d’interface utilisateur

    • Créer un nœud d’interface utilisateur de base et personnalisé : CustomNodeModel.cs

    • Créer un menu déroulant : DropDown.cs

  • Tests

    • Tests système : HelloDynamoSystemTests.cs

    • Tests ZeroTouch : HelloDynamoZeroTouchTests.cs

  • Exemples ZeroTouch :

    • Exemple de nœuds ZeroTouch, dont un qui implémente IGraphicItem pour affecter le rendu de la géométrie : BasicExample.cs

    • Exemple de nœuds ZeroTouch pour colorer la géométrie en utilisant IRenderPackage: ColorExample.cs

  • Exemples d’extension de vue : implémentation IViewExtension qui affiche une fenêtre non modale lorsque l’utilisateur clique sur son élément MenuItem.

• NodeModelsEssentials: modèles pour le développement avancé de packages Dynamo à l’aide de NodeModel.

  • Exemples essentiels :

    • Erreur

    • MultiOperation

    • Multiplier

    • Délai

  • Exemples de géométrie :

    • CustomPreview

    • SurfaceFrom4Points

    • UVPlanesOnSurface

    • WobblySurface

  • Exemples d’interface utilisateur :

    • Bouton

    • ButtonFunction

    • CopyableWatch

    • Tiroir

    • SliderBound

    • Etat

DynamicText: bibliothèque ZeroTouch permettant de créer du texte dans Dynamo.

Étude de cas

Les développeurs tiers ont apporté des contributions significatives et intéressantes à la plateforme, dont beaucoup sont également en open source. Les projets suivants sont des exemples exceptionnels de ce qu’il est possible de faire avec Dynamo.

Ladybug est une bibliothèque Python qui permet de charger, d’analyser et de modifier les fichiers EneregyPlus Weather (epw).

https://github.com/ladybug-tools/ladybug

Honeybee est une bibliothèque Python qui permet de créer, d’exécuter et de visualiser les résultats d’analyses de la lumière du jour (RADIANCE) et de l’énergie (EnergyPlus/OpenStudio).

https://github.com/ladybug-tools/honeybee

Bumblebee est un plugin pour l’interopérabilité entre Excel et Dynamo (GPL).

https://github.com/ksobon/Bumblebee

Clockwork est une collection de nœuds personnalisés pour les activités liées à Revit ainsi que pour d’autres opérations telles que la gestion de listes, les opérations mathématiques, les opérations de chaîne, les opérations géométriques (principalement des zones de délimitation, des maillages, des plans, des points, des surfaces, des UV et des vecteurs) et la création de panneaux.

https://github.com/andydandy74/ClockworkForDynamo

Extensions en tant que packages

Vue d’ensemble

Les extensions Dynamo peuvent être déployées dans le gestionnaire de package tout comme les bibliothèques de nœuds Dynamo. Lorsqu’un package installé contient une extension de vue, l’extension est chargée à l’exécution lors du chargement de Dynamo. Vous pouvez vérifier dans la console Dynamo que l’extension a été correctement chargée.

Structure du package

La structure d’un package d’extension est la même que celle d’un package normal contenant...

C:\Users\User\AppData\Roaming\Dynamo\Dynamo Core\2.1\packages\Sample View Extension
│   pkg.json
├───bin
│       SampleViewExtension.dll
├───dyf
└───extra
        SampleViewExtension_ViewExtensionDefinition.xml

En supposant que vous ayez déjà créé votre extension, vous disposerez (au minimum) d’un assemblage .NET et d’un fichier manifest. L’assemblage doit contenir une classe qui implémente IViewExtension ou IExtension. Le fichier manifest .XML indique à Dynamo la classe à instancier pour lancer votre extension. Pour que le gestionnaire de package puisse localiser correctement l’extension, le fichier manifest doit correspondre exactement à l’emplacement et au nom de l’assemblage.

Placez les fichiers d’assemblage dans le dossier bin et le fichier manifest dans le dossier extra. Toutes les ressources supplémentaires peuvent également être placées dans ce dossier.

Exemple de fichier manifest .XML :

<ViewExtensionDefinition>
  <AssemblyPath>..\bin\MyViewExtension.dll</AssemblyPath>
  <TypeName>MyViewExtension.MyViewExtension</TypeName>
</ViewExtensionDefinition>

Téléchargement

Une fois que vous avez un dossier contenant les sous-répertoires décrits ci-dessus, vous êtes prêt à envoyer (télécharger) vers le gestionnaire de package. Notez que vous ne pouvez pas publier de packages à partir de Dynamo Sandbox. Cela signifie que vous devez utiliser Dynamo Revit. Une fois dans Dynamo Revit, accédez à Packages => Publier le nouveau package. Cette opération invite l’utilisateur à se connecter à son compte Autodesk auquel il souhaite associer le package.

À ce stade, vous devriez vous trouver dans la fenêtre normale de publication de package où vous saisirez tous les champs requis concernant votre package/extension. Il existe une étape supplémentaire très importante qui nécessite de s’assurer qu’aucun de vos fichiers d’assemblage n’est marqué comme bibliothèque de nœuds. Pour ce faire, cliquez avec le bouton droit de la souris sur les fichiers que vous avez importés (dossier de package créé ci-dessus). Un menu contextuel apparaît et vous permet de cocher (ou décocher) cette option. Tous les assemblages d’extension doivent être décochés.

Avant de publier publiquement, vous devez toujours publier localement pour vous assurer que tout fonctionne comme prévu. Une fois la vérification terminée, vous pouvez démarrer en ligne en sélectionnant Publier.

Tirer

Pour vérifier que votre package a été correctement téléchargé, vous devez être en mesure de le rechercher en fonction du nom et des mots clés spécifiés lors de l’étape de publication. Enfin, il est important de noter que ces extensions nécessitent un redémarrage de Dynamo avant de fonctionner. En général, ces extensions requièrent des paramètres spécifiés lors du démarrage de Dynamo.

Publier un package

Les packages sont un moyen pratique de stocker et de partager des nœuds avec la communauté Dynamo. Un package peut contenir tout ce qui est nécessaire, des nœuds personnalisés créés dans l’espace de travail Dynamo aux nœuds dérivés de NodeModel. Les packages sont publiés et installés à l’aide du gestionnaire de package. En plus de cette page, le guide contient un guide général sur les packages.

Qu’est-ce qu’un gestionnaire de package ?

Le gestionnaire de package Dynamo est un registre de logiciels (similaire à npm) accessible à partir de Dynamo ou d’un navigateur web. Le gestionnaire de package comprend l’installation, la publication, la mise à jour et la visualisation des packages. Comme npm, il conserve différentes versions des packages. Il permet également de gérer les dépendances de votre projet.

Dans le navigateur, recherchez des packages et consultez les statistiques : https://dynamopackages.com/

• Dans Dynamo, le gestionnaire de package inclut les packages d’installation, de publication et de mise à jour.

1. Rechercher des packages en ligne : Packages > Search for a Package...

2. Afficher/modifier les packages installés : Packages > Manage Packages...

3. Publier un nouveau package : Packages > Publish New Package...

Publier un package

Les packages sont publiés à partir du gestionnaire de package dans Dynamo. Le processus recommandé consiste à publier localement, tester le package, puis publier en ligne pour le partager avec la communauté. En utilisant l’étude de cas NodeModel, nous allons suivre les étapes nécessaires pour publier le nœud RectangularGrid en tant que package localement et ensuite en ligne.

Lancez Dynamo et sélectionnez Packages > Publish New Package... pour ouvrir la fenêtre Publish a Package.

1. Sélectionnez Add file... pour rechercher les fichiers à ajouter au package

2. Sélectionnez les deux fichiers .dll dans l’étude de cas NodeModel

3. Sélectionnez Ok

Une fois les fichiers ajoutés au contenu du package, donnez-lui un nom, une description et une version. Publier un package avec Dynamo crée automatiquement un fichier pkg.json.

Un package prêt à être publié.

1. Renseignez les informations requises pour le nom, la description et la version.

2. Publiez en cliquant sur « Publier localement » et sélectionnez le dossier de package de Dynamo : AppData\Roaming\Dynamo\Dynamo Core\1.3\packages pour que le nœud soit disponible dans Core. Publiez toujours localement jusqu’à ce que le package soit prêt à être partagé.

Après avoir publié un package, les nœuds seront disponibles dans la bibliothèque Dynamo sous la catégorie CustomNodeModel.

1. Le package que nous venons de créer dans la bibliothèque Dynamo

Une fois que le package est prêt à être publié en ligne, ouvrez le gestionnaire de package et choisissez Publish puis Publish Online.

1. Pour voir comment Dynamo a formaté le package, cliquez sur les trois points verticaux à droite de « CustomNodeModel » et choisissez « Afficher le répertoire racine ».

2. Sélectionnez Publish, puis Publish Online dans la fenêtre « Publier un package Dynamo ».

3. Pour supprimer un package, sélectionnez Delete.

Comment mettre à jour un package ?

La mise à jour d’un package est un processus similaire à la publication. Ouvrez le gestionnaire de package et sélectionnez Publish Version... sur le package à mettre à jour, puis entrez une version supérieure.

1. Sélectionnez Publish Version pour mettre à jour un package existant avec de nouveaux fichiers dans le répertoire racine, puis choisissez s’il doit être publié localement ou en ligne.

Client Web du gestionnaire de package

Le client Web du gestionnaire de package est utilisé exclusivement pour rechercher et afficher des données de package, telles que le contrôle des versions et les statistiques de téléchargement.

Le client Web du gestionnaire de package est accessible à l’adresse suivante : https://dynamopackages.com/

Si vous développez des assemblages destinés à être publiés sous forme de package pour Dynamo, le projet peut être configuré pour regrouper toutes les ressources nécessaires et les placer dans une structure de répertoire compatible avec le package. Cela permettra de tester rapidement le projet en tant que package et de simuler l’expérience d’un utilisateur.

Comment générer directement dans le dossier du package

Il existe deux méthodes pour générer un package dans Visual Studio :

• ajouter des événements après la génération via la boîte de dialogue Paramètres du projet qui utilisent xcopy ou des scripts Python pour copier les fichiers nécessaires ;

• utiliser la cible de génération « AfterBuild » dans le fichier .csproj pour créer des tâches de copie de fichiers et de répertoires.

« AfterBuild » est la méthode préférée pour ces types d’opérations (et celle couverte par ce guide) car elle ne repose pas sur la copie de fichiers qui peuvent ne pas être disponibles sur la machine de génération.

Copier des fichiers de package à l’aide de la méthode AfterBuild

Configurez la structure de répertoires dans le dépôt de sorte que les fichiers source soient séparés des fichiers de package. En travaillant avec l’étude de cas CustomNodeModel, placez le projet Visual Studio et tous les fichiers associés dans un nouveau dossier src. C’est dans ce dossier que seront stockés tous les packages générés par le projet. La structure du dossier devrait maintenant être la suivante :

CustomNodeModel
> src
  > CustomNodeModel
  > CustomNodeModelFunction
  > packages
  > CustomNodeModel.sln

1. Déplacez les fichiers de projet vers le nouveau dossier src.

Maintenant que les fichiers source se trouvent dans un dossier distinct, ajoutez une cible AfterBuild au fichier CustomNodeModel.csproj dans Visual Studio. Cela devrait permettre de copier les fichiers nécessaires dans un nouveau dossier de package. Ouvrez le fichier CustomNodeModel.csproj dans un éditeur de texte (nous avons utilisé Atom) et placez la cible de génération avant la balise de fermeture </Project>. Cette cible AfterBuild copie tous les fichiers .dll, .pbd, .xml et .config dans un nouveau dossier bin et crée un fichier dyf et des dossiers supplémentaires.

  <Target Name="AfterBuild">
    <ItemGroup>
      <Dlls Include="$(OutDir)*.dll" />
      <Pdbs Include="$(OutDir)*.pdb" />
      <Xmls Include="$(OutDir)*.xml" />
      <Configs Include="$(OutDir)*.config" />
    </ItemGroup>
    <Copy SourceFiles="@(Dlls)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />
    <Copy SourceFiles="@(Pdbs)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />
    <Copy SourceFiles="@(Xmls)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />
    <Copy SourceFiles="@(Configs)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />
    <MakeDir Directories="$(SolutionDir)..\packages\CustomNodeModel\dyf" />
    <MakeDir Directories="$(SolutionDir)..\packages\CustomNodeModel\extra" />
  </Target>

Nous devons nous assurer que la cible a été ajoutée au fichier CustomNodeModel.csproj (et non à un autre fichier de projet) et que le projet ne possède aucun paramètre postérieur à la génération.

1. Placez la cible AfterBuild avant la balise de fin </Project>.

Dans la section <ItemGroup>, un certain nombre de variables sont définies pour représenter des types de fichiers spécifiques. Par exemple, la variable Dll représente tous les fichiers du répertoire de sortie dont l’extension est .dll.

<ItemGroup>
  <Dlls Include="$(OutDir)*.dll" />
</ItemGroup>

La tâche Copy consiste à copier tous les fichiers .dll dans un répertoire, en particulier le dossier de package vers lequel se fait la génération.

<Copy SourceFiles="@(Dlls)" DestinationFolder="$(SolutionDir)..\packages\CustomNodeModel\bin\" />

Les packages Dynamo possèdent généralement un dossier dyf et extra pour les nœuds personnalisés Dynamo et d’autres ressources telles que des images. Pour créer ces dossiers, nous devons utiliser une tâche MakeDir. Cette tâche crée un dossier s’il n’existe pas. Vous pouvez ajouter des fichiers manuellement à ce dossier.

<MakeDir Directories="$(SolutionDir)..\packages\CustomNodeModel\extra" />

Si vous générez le projet, le dossier de projet doit désormais comporter un dossier packages en plus du dossier src créé précédemment. Le répertoire packages contient un dossier contenant tous les éléments nécessaires au package. Vous devez également copier le fichier pkg.json dans le dossier du package afin que Dynamo sache comment charger le package.

1. Le nouveau dossier de packages créé par la cible AfterBuild

2. Le dossier src existant avec le projet

3. Les dossiers dyf et extra créés à partir de la cible AfterBuild

4. Copiez manuellement le fichier pkg.json

Vous pouvez désormais publier le package à l’aide du gestionnaire de package de Dynamo ou le copier directement dans le répertoire de package de Dynamo : <user>\AppData\Roaming\Dynamo\1.3\packages.