Antes de entrar no desenvolvimento, é importante compilar uma base sólida para um novo projeto. Há vários modelos de projeto na comunidade de desenvolvedores do Dynamo que são excelentes locais para começar, mas uma compreensão de como iniciar um projeto do zero é ainda mais valiosa. A compilação de um projeto desde o início proporcionará uma compreensão mais profunda do processo de desenvolvimento.

Criar um projeto do Visual Studio

O Visual Studio é um IDE poderoso, onde podemos criar um projeto, adicionar referências, compilar .dlls e depurar. Ao criar um novo projeto, o Visual Studio também criará uma Solução, uma estrutura para organizar projetos. Vários projetos podem existir em uma única solução e podem ser compilados juntos. Para criar um nó Sem toque, precisaremos iniciar um novo projeto do Visual Studio no qual gravaremos uma biblioteca de classe C# e compilaremos um .dll.

Janela Novo projeto no Visual Studio

1. Começar abrindo o Visual Studio e criando um novo projeto: File > New > Project

2. Selecionar o modelo de projeto Class Library

3. Nomear o projeto (nomeamos o projeto MyCustomNode)

4. Definir o caminho do arquivo para o projeto. Para este exemplo, vamos deixá-lo na localização padrão

5. Selecionar Ok

O Visual Studio criará e abrirá automaticamente um arquivo C#. Deve ser atribuído um nome apropriado, deve ser configurado o espaço de trabalho e substituído o código padrão por este método de multiplicação.

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

1. Abrir o Gerenciador de soluções e as janelas Saída em View.

2. Renomear o arquivo Class1.cs SampleFunctions.cs no Gerenciador de soluções à direita.

3. Adicionar o código acima para a função de multiplicação. Abordaremos as especificações de como o Dynamo lerá as classes C# mais adiante.

4. O Gerenciador de soluções fornece acesso a tudo no projeto.

5. Janela Saída: precisaremos dela mais tarde para ver se a compilação foi bem-sucedida.

A próxima etapa é compilar o projeto, mas antes de fazer isso, há algumas configurações que precisamos verificar. Primeiro, assegure-se de que Any CPU ou x64 esteja selecionado como o destino da plataforma e que Prefer 32-bit esteja desmarcado nas Propriedades do projeto.

1. Abrir as propriedades do projeto selecionando Project > "ProjectName" Properties

2. Selecionar a página Build

3. Selecionar Any CPU ou x64 no menu suspenso

4. Garantir que Prefer 32-bit está desmarcado

Agora podemos compilar o projeto para criar um .dll. Para isso, selecione Build Solution no menu Build ou use o atalho CTRL+SHIFT+B.

1. Selecionar Build > Build Solution

2. É possível determinar se o projeto foi compilado com êxito verificando a janela Saída

Se o projeto tiver sido compilado com êxito, haverá um .dll nomeado MyCustomNode na pasta do projeto bin. Para este exemplo, deixamos o caminho de arquivo do projeto como padrão do Visual Studio em c:\users\username\documents\visual studio 2015\Projects. Vamos dar uma olhada na estrutura de arquivos do projeto.

1. A pasta bin contém o .dll criado no Visual Studio.

2. O arquivo de projeto do Visual Studio.

3. O arquivo de classe.

4. Como nossa configuração de solução foi definida como Debug, o .dll será criado em bin\Debug.

Agora, podemos abrir o Dynamo e importar o .dll. Com o recurso Adicionar, navegue até a localização do projeto bin e selecione o .dll que deseja abrir.

1. Selecionar o botão Adicionar para importar um .dll

2. Navegar até a localização do projeto. Nosso projeto está localizado no caminho de arquivo padrão do Visual Studio: C:\Users\username\Documents\Visual Studio 2015\Projects\MyCustomNode

3. Selecionar o MyCustomNode.dll a ser importado

4. Clicar em Open para carregar o .dll

Se uma categoria for criada na biblioteca chamada MyCustomNode, significa que o .dll foi importado com êxito. No entanto, o Dynamo criou dois nós do que queríamos ser um nó único. Na próxima seção, explicaremos por que isso acontece e como o Dynamo lê um .dll.

1. MyCustomNode na biblioteca do Dynamo. A categoria da biblioteca é determinada pelo nome .dll.

2. SampleFunctions.MultiplyByTwo na tela.

Como o Dynamo lê as classes e os métodos

Quando o Dynamo carrega um .dll, ele expõe todos os métodos estáticos públicos como nós. Construtores, métodos e propriedades serão transformados em nós Criar, Ação e Consulta, respectivamente. No nosso exemplo de multiplicação, o método MultiplyByTwo() se torna num nó Ação no Dynamo. Isso ocorre porque o nó foi nomeado com base em seu método e classe.

1. A entrada é nomeada inputNumber com base no nome do parâmetro do método.

2. A saída é nomeada double por padrão porque esse é o tipo de dados que está sendo retornado.

3. O nó é nomeado SampleFunctions.MultiplyByTwo porque esses são os nomes de classe e método.

No exemplo acima, o nó adicional Criar SampleFunctions foi criado porque não fornecemos explicitamente um construtor e, portanto, um foi criado automaticamente. Podemos evitar isso criando um construtor privado vazio em nossa 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. O Dynamo importou nosso método como um nó Criar

Adicionar referências do pacote NuGet do Dynamo

O nó de multiplicação é muito simples e não é necessário fazer referências ao Dynamo. Se quisermos acessar qualquer funcionalidade do Dynamo para criar geometria, por exemplo, precisaremos fazer referência aos pacotes NuGet do Dynamo.

• ZeroTouchLibrary – Pacote para a compilação de bibliotecas de nós sem toque para o Dynamo que contém as seguintes bibliotecas: DynamoUnits.dll, ProtoGeometry.dll

• WpfUILibrary – Pacote para bibliotecas de nós de compilação do Dynamo com interface de usuário personalizada no WPF que contém as seguintes bibliotecas: DynamoCoreWpf.dll, CoreNodeModels.dll, CoreNodeModelWpf.dll

• DynamoServices – Biblioteca do DynamoServices para o Dynamo

• Core – Infraestrutura de teste da unidade e do sistema para o Dynamo que contém as seguintes bibliotecas: DSIronPython.dll, DynamoApplications.dll, DynamoCore.dll, DynamoInstallDetetive.dll, DynamoShapeManager.dll, DynamoUtilities.dll, ProtoCore.dll, VMDataBridge.dll

• Tests – Infraestrutura de teste da unidade e do sistema para o Dynamo que contém as seguintes bibliotecas: DynamoCoreTests.dll, SystemTestServices.dll, TestServices.dll

• DynamoCoreNodes – Pacote para a compilação de nós principais do Dynamo que contém as seguintes bibliotecas: Analysis.dll, GeometryColor.dll, DSCoreNodes.dll

Para fazer referência a esses pacotes em um projeto do Visual Studio, faça o download do pacote NuGet nos links acima e faça referência manualmente aos .dlls ou use o Gerenciador de pacotes NuGet no Visual Studio. Primeiro, podemos analisar como instalá-los com o NuGet no Visual Studio.

1. Abra o Gerenciador de pacotes NuGet selecionando Tools > NuGet Package Manager > Manage NuGet Packages for Solution...

Esse é o Gerenciador de pacotes NuGet. Essa janela mostra quais pacotes foram instalados para o projeto e permite que o usuário procure outros. Se uma nova versão do pacote DynamoServices for liberada, os pacotes poderão ser atualizados daqui ou revertidos para uma versão anterior.

1. Selecionar Procurar e pesquisar DynamoVisualProgramming para ativar os pacotes do Dynamo.

2. Pacotes do Dynamo. Selecionar um mostrará a versão atual e a descrição do que está dentro.

3. Selecionar a versão do pacote necessária e clicar em instalar. Isso instala um pacote para o projeto específico no qual você está trabalhando. Como estamos usando a versão estável mais recente do Dynamo, a versão 1.3, escolha a versão do pacote correspondente.

Para adicionar manualmente um pacote transferido por download do navegador, abra o Gerenciador de referências no Gerenciador de soluções e procure o pacote.

1. Clicar com o botão direito do mouse em References e selecionar Add Reference.

2. Selecionar Browse para navegar para a localização do pacote.

Agora que o Visual Studio está configurado corretamente e adicionamos com êxito um .dll ao Dynamo, temos uma base sólida para os conceitos daqui para frente. Este é apenas o início, portanto, siga em frente para saber mais sobre como criar um nó personalizado.

Introdução

Esta seção contém informações sobre problemas que podem ocorrer durante a migração dos gráficos, dos pacotes e das bibliotecas para o Dynamo 3.x.

O Dynamo 3.0 é uma versão principal e algumas APIs foram alteradas ou removidas. A maior alteração que provavelmente afetará você como desenvolvedor ou usuário do Dynamo 3.x é a mudança para .NET8.

Dotnet/.NET é o tempo de execução que alimenta a linguagem C# na qual o Dynamo está escrito. Atualizamos para uma versão moderna deste tempo de execução junto com o resto do ecossistema da Autodesk.

Você pode ler mais em nossa postagem de blog.

Compatibilidade dos pacotes

Usar pacotes do Dynamo 2.x no Dynamo 3.x

Como o Dynamo 3.x agora é executado no tempo de execução do .NET8, não é garantido que os pacotes que foram criados para o Dynamo 2.x (usando o .NET48) funcionem no Dynamo 3.x. Quando você tentar fazer download de um pacote no Dynamo 3.x que foi publicado de uma versão do Dynamo inferior a 3.0, receberá um aviso de que o pacote é de uma versão anterior do Dynamo.

Isso não significa que o pacote não funcionará É simplesmente um aviso de que podem ocorrer problemas de compatibilidade e, em geral, é uma boa ideia verificar se há uma versão mais recente que tenha sido criada especificamente para o Dynamo 3.x.

Você também pode observar esse tipo de aviso nos arquivos de registro do Dynamo no momento da carga do pacote. Se tudo estiver funcionando corretamente, será possível ignorá-lo.

Usar pacotes do Dynamo 3.x no Dynamo 2.x

É muito improvável que um pacote criado para o Dynamo 3.x (usando .Net8) funcione no Dynamo 2.x. Você também verá um aviso ao fazer o download de pacotes criados para versões mais recentes do Dynamo enquanto usa uma versão mais antiga.

Independentemente do nível de experiência, a plataforma do Dynamo foi projetada para que todos os usuários sejam colaboradores. Há diversas opções de desenvolvimento voltadas para diferentes capacidades e níveis de habilidades, cada uma com seus pontos fortes e fracos, dependendo do objetivo. Abaixo, descreveremos as diferentes opções e como escolher uma em detrimento de outra.

Três ambientes de desenvolvimento: Visual Studio, Editor do Python e DesignScript com Blocos de código

Quais são as minhas opções?

As opções de desenvolvimento do Dynamo são divididas principalmente em duas categorias: para o Dynamo versus no Dynamo. As duas categorias podem ser consideradas semelhantes; “no” Dynamo implica o conteúdo criado usando o IDE do Dynamo para ser usado no Dynamo e “para” o Dynamo implica o uso de ferramentas externas para criar conteúdo a ser importado para o Dynamo para ser usado. Embora este guia se concentre no desenvolvimento para o Dynamo, os recursos para todos os processos são descritos abaixo.

Para o Dynamo

Estes nós permitem o maior grau de personalização. Muitos pacotes são criados com esse método e é necessário para contribuir para a origem do Dynamo. O processo de compilação deles será abordado neste guia.

• Nós Sem toque

• Nós derivados do NodeModel

• Extensões

O Manual tem um guia sobre como importar bibliotecas Sem toque.

Para a discussão abaixo, o Visual Studio é usado como o ambiente de desenvolvimento para os nós Sem toque e NodeModel.

A interface do Visual Studio com um projeto que desenvolveremos

No Dynamo

Embora esses processos existam no espaço de trabalho de programação visual e sejam relativamente diretos, todos eles são opções viáveis para personalizar o Dynamo. O Manual cobre esses tópicos extensivamente e fornece dicas de scripts e as práticas recomendadas no capítulo Estratégias de script.

• Os Blocos de código expõem o DesignScript no ambiente de programação visual, permitindo fluxos de trabalho flexíveis de scripts de texto e nós. Uma função em um bloco de código pode ser chamada por qualquer item no espaço de trabalho.

  Faça o download de um exemplo de bloco de código (clique com o botão direito do mouse e salve como) ou veja um percurso virtual detalhado no Manual.

• Os nós personalizados são contêineres para coleções de nós ou até mesmo gráficos inteiros. Eles são uma forma eficaz de coletar rotinas usadas com frequência e compartilhá-las com a comunidade.

  Faça o download de um exemplo de nó personalizado (clique com o botão direito do mouse e salve como) ou veja um percurso virtual detalhado no Manual.

• Os nós Python são uma interface de scripts no espaço de trabalho de programação visual, semelhante aos blocos de código. As bibliotecas Autodesk.DesignScript usam uma notação de ponto similar ao DesignScript.

  Faça o download de um exemplo de nó Python (clique com o botão direito do mouse e salve como) ou veja um percurso virtual detalhado no Manual

O desenvolvimento no espaço de trabalho do Dynamo é uma ferramenta poderosa para obter feedback imediato.

Desenvolvimento no espaço de trabalho do Dynamo com o nó Python

Quais são as vantagens/desvantagens de cada um?

As opções de desenvolvimento do Dynamo foram projetadas para lidar com a complexidade de uma necessidade de personalização. Se o objetivo é escrever um script recursivo no Python ou compilar uma interface de usuário de nó totalmente personalizada, há opções para implementar código que envolvem apenas o que é necessário para começar a trabalhar.

Blocos de código, nó Python e nós personalizados no Dynamo

Essas são opções simples para escrever código no ambiente de programação visual do Dynamo. O espaço de trabalho de programação visual do Dynamo fornece acesso ao Python, ao DesignScript e à capacidade de conter vários nós dentro de um nó personalizado.

Com esses métodos, podemos:

• Começar a escrever Python ou DesignScript com pouca ou nenhuma configuração.

• Importar bibliotecas Python para o Dynamo.

• Compartilhar blocos de código, nós Python e nós personalizados com a comunidade do Dynamo como parte de um pacote.

Nós Sem toque

O nó Sem toque é um método simples de apontar e clicar para importar bibliotecas C#. O Dynamo lê os métodos públicos de um .dll e os converte em nós do Dynamo. É possível usar o nó Sem toque para desenvolver seus próprios nós e pacotes personalizados.

Com esse método, podemos:

• Importar uma biblioteca que não foi necessariamente desenvolvida para o Dynamo e criar automaticamente um conjunto de novos nós, como o exemplo A-Forge no Manual

• Escrever métodos C# e usar facilmente os métodos como nós no Dynamo

• Compartilhar uma biblioteca C# como nós com a comunidade do Dynamo em um pacote

Nós derivados do NodeModel

Esses nós são um passo mais profundo na estrutura do Dynamo. Eles são baseados na classe NodeModel e escritos em C#. Embora esse método forneça a maior flexibilidade e potência, a maioria dos aspectos do nó precisa ser explicitamente definida e as funções precisam residir em uma montagem separada.

Com esse método, podemos:

• Criar uma interface de usuário de nó totalmente personalizável com controles deslizantes, imagens, cores etc. (por exemplo, nó ColorRange)

• Acessar e afetar o que está acontecendo na tela do Dynamo

• Personalizar a amarra

• Carregar no Dynamo como um pacote

Entender o controle de versão do Dynamo e as alterações da API (1.x → 2.x)

Como o Dynamo está sendo atualizado regularmente, as alterações podem ser feitas em parte da API que um pacote usa. O rastreamento dessas alterações é importante para garantir que os pacotes existentes continuem a funcionar corretamente.

As alterações da API são rastreadas no Wiki do Dynamo Github. Isso abrange as alterações no DynamoCore, nas bibliotecas e nos espaços de trabalho.

Um exemplo de uma mudança significativa futura é a transição do formato de arquivo XML para o formato JSON na versão 2.0. Os nós derivados do NodeModel agora precisarão de um construtor JSON; caso contrário, eles não serão abertos no Dynamo 2.0.

A documentação da API do Dynamo atualmente cobre a funcionalidade principal: http://dynamods.github.io/DynamoAPI

Permissão para distribuir binários em um pacote

Esteja ciente de que os .dll estão incluídos em um pacote que está sendo carregado no gerenciador de pacotes. Se o autor do pacote não tiver criado o .dll, ele deverá ter os direitos para compartilhá-lo.

Se um pacote incluir binários, os usuários deverão ser informados, ao fazer o download, de que o pacote contém binários.

Com um entendimento de como criar um projeto Sem toque, podemos nos aprofundar nos detalhes específicos da criação de um nó ao navegar pelo exemplo ZeroTouchEssentials no Dynamo Github.

Muitos dos nós padrão do Dynamo são essencialmente nós Sem toque, como a maioria dos nós matemáticos, de cor e de data e hora acima.

Para iniciar, faça o download do projeto ZeroTouchEssentials aqui: https://github.com/DynamoDS/ZeroTouchEssentials

No Visual Studio, abra o arquivo de solução ZeroTouchEssentials.sln e compile a solução.

O arquivo ZeroTouchEssentials.cs contém todos os métodos que iremos importar para o Dynamo.

Abra o Dynamo e importe o ZeroTouchEssentials.dll para obter os nós que faremos referência nos exemplos a seguir.

Os exemplos de código são extraídos e geralmente coincidem com ZeroTouchEssentials.cs. A documentação XML foi removida para mantê-los concisos, e cada exemplo de código criará o nó na imagem acima dele.

Valores de entrada padrão

O Dynamo suporta a definição de valores padrão para portas de entrada em um nó. Esses valores padrão serão fornecidos ao nó se as portas não tiverem conexões. Os padrões são expressos usando o mecanismo C# de especificação de argumentos opcionais no Guia de programação C#. Os valores padrão são especificados da seguinte maneira:

• Defina os parâmetros do método para um valor padrão: inputNumber = 2.0

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        // Set the method parameter to a default value
        public static double MultiplyByTwo(double inputNumber = 2.0) 
        {
            return inputNumber * 2.0;
        }
    }
}

1. O valor padrão será exibido quando você passar o cursor sobre a porta de entrada do nó

Retornar vários valores

Retornar vários valores é um pouco mais complexo do que criar várias entradas e isso precisará ser feito usando um dicionário. As entradas do dicionário se tornam portas no lado de saída do nó. Várias portas de retorno são criadas da seguinte maneira:

• Adicione using System.Collections.Generic; para usar Dictionary<>.

• Adicione using Autodesk.DesignScript.Runtime; para usar o atributo MultiReturn. Isso faz referência ao “DynamoServices.dll” do pacote DynamoServices NuGet.

• Adicione o atributo [MultiReturn(new[] { "string1", "string2", ... more strings here })] ao método. As sequências de caracteres se referem às chaves no dicionário e se tornarão os nomes das portas de saída.

• Retorne um Dictionary<> da função com chaves que coincidem com os nomes de parâmetro no atributo: return new Dictionary<string, object>

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

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        [MultiReturn(new[] { "add", "mult" })]
        public static Dictionary<string, object> ReturnMultiExample(double a, double b)
        {
            return new Dictionary<string, object>

                { "add", (a + b) },
                { "mult", (a * b) }
            };
        }
    }
}

Consulte este exemplo de código em ZeroTouchEssentials.cs

Um nó que retorna várias saídas.

1. Observe que agora há duas portas de saída nomeadas de acordo com as sequências que inserimos para as chaves do dicionário.

Documentação, dicas de ferramentas e pesquisa

É recomendável adicionar documentação aos nós do Dynamo que descrevam a função, as entradas, as saídas, os identificadores de pesquisa do nó etc. Isso é feito por meio de identificadores de documentação XML. A documentação XML é criada da seguinte maneira:

• Qualquer texto de comentário que é precedido por três barras inclinadas adiante é considerado como documentação

  • Por exemplo: /// Documentation text and XML goes here

• Após as três barras, crie identificadores XML acima dos métodos que o Dynamo lerá ao importar o .dll

  • Por exemplo: /// <summary>...</summary>

• Ative a documentação XML no Visual Studio selecionando Project > Project Properties > Build e verificando XML documentation file

1. O Visual Studio gerará um arquivo XML na localização especificada

Os tipos de identificadores são os seguintes:

• /// <summary>...</summary> é a documentação principal do nó e será exibida como uma dica de ferramenta sobre o nó na barra lateral esquerda de pesquisa

• /// <param name="inputName">...</param> criará a documentação para os parâmetros de entrada específicos

• /// <returns>...</returns> criará a documentação para um parâmetro de saída

• /// <returns name = "outputName">...</returns> criará a documentação para vários parâmetros de saída

• /// <search>...</search> corresponderá o nó aos resultados da pesquisa com base em uma lista separada por vírgulas. Por exemplo, se criarmos um nó que subdivide uma malha, poderemos desejar adicionar identificadores como “malha”, “subdivisão” e “catmull-Clark”.

A seguir está um nó de exemplo com descrições de entrada e saída, bem como um resumo que será exibido na biblioteca.

using Autodesk.DesignScript.Geometry;

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        /// <summary>
        /// This method demonstrates how to use a native geometry object from Dynamo
        /// in a custom method
        /// </summary>
        /// <param name="curve">Input Curve. This can be of any type deriving from Curve, such as NurbsCurve, Arc, Circle, etc</param>
        /// <returns>The twice the length of the Curve </returns>
        /// <search>example,curve</search>
        public static double DoubleLength(Curve curve)
        {
            return curve.Length * 2.0;
        }
    }
}

Consulte este exemplo de código em ZeroTouchEssentials.cs

Observe que o código para esse nó de exemplo contém:

1. Um resumo dos nós

2. Uma descrição de entrada

3. Uma descrição de saída

Objetos

O Dynamo não tem uma palavra-chave new, portanto, os objetos precisarão ser construídos usando métodos de construção estáticos. Os objetos são construídos da seguinte maneira:

• Tornar o construtor interno internal ZeroTouchEssentials(), a menos que seja necessário de outra forma

• Construir o objeto com um método estático como public static ZeroTouchEssentials ByTwoDoubles(a, b)

Observação: O Dynamo usa o prefixo “Por” para indicar que um método estático é um construtor e, embora seja opcional, usar “Por” ajudará a biblioteca a se ajustar melhor ao estilo existente do Dynamo.

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        private double _a;
        private double _b;

        // Make the constructor internal
        internal ZeroTouchEssentials(double a, double b)
        {
            _a = a;
            _b = b;
        }

        // The static method that Dynamo will convert into a Create node
        public static ZeroTouchEssentials ByTwoDoubles(double a, double b)
        {
            return new ZeroTouchEssentials(a, b);
        }
    }
}

Consulte este exemplo de código em ZeroTouchEssentials.cs

Após a importação do dll ZeroTouchEssentials, haverá um nó ZeroTouchEssentials na biblioteca. É possível criar esse objeto usando o nó ByTwoDoubles.

Usar tipos de geometria do Dynamo

As bibliotecas do Dynamo podem usar tipos de geometria nativos do Dynamo como entradas e criar uma nova geometria como saídas. Os tipos de geometria são criados da seguinte maneira:

• Referenciar “ProtoGeometry.dll” no projeto incluindo using Autodesk.DesignScript.Geometry; na parte superior do arquivo C# e adicionando o pacote NuGet da ZeroTouchLibrary ao projeto.

• Importante: Gerencie os recursos de geometria que não são retornados das funções. Consulte a seção Dispor/usar declarações abaixo.

Observação: Os objetos de geometria do Dynamo são usados como qualquer outro objeto passado para funções.

using Autodesk.DesignScript.Geometry;

namespace ZeroTouchEssentials
{
    public class ZeroTouchEssentials
    {
        // "Autodesk.DesignScript.Geometry.Curve" is specifying the type of geometry input, 
        // just as you would specify a double, string, or integer 
        public static double DoubleLength(Autodesk.DesignScript.Geometry.Curve curve)
        {
            return curve.Length * 2.0;
        }
    }
}

Consulte este exemplo de código em ZeroTouchEssentials.cs

Um nó que obtém o comprimento de uma curva e o duplica.

1. Esse nó aceita um tipo de geometria de curva como uma entrada.

Dispor/usar declarações

Os recursos de geometria que não são retornados de funções precisarão ser gerenciados manualmente, a não ser que você esteja usando o Dynamo versão 2.5 ou posterior. No Dynamo 2.5 e versões posteriores, os recursos de geometria são manipulados internamente pelo sistema. No entanto, talvez você ainda precise descartar a geometria manualmente se tiver um caso de uso complexo ou precisar reduzir a memória em um momento determinado. O mecanismo do Dynamo lidará com quaisquer recursos de geometria que são retornados de funções. Os recursos de geometria que não são retornados podem ser manipulados manualmente das seguintes maneiras:

• Com uma declaração de uso:

  Copy

  using (Point p1 = Point.ByCoordinates(0, 0, 0))
  {
    using (Point p2 = Point.ByCoordinates(10, 10, 0))
    {
        return Line.ByStartPointEndPoint(p1, p2);
    }
  }

  A declaração de uso está documentada aqui

  Consulte Melhorias na estabilidade da geometria do Dynamo para saber mais sobre os novos recursos de estabilidade introduzidos no Dynamo 2.5

• Com chamadas Dispor manuais:

  Copy

  Point p1 = Point.ByCoordinates(0, 0, 0);
  Point p2 = Point.ByCoordinates(10, 10, 0);
  Line l = Line.ByStartPointEndPoint(p1, p2);
  p1.Dispose();
  p2.Dispose();
  return l;

Migrações

Ao publicar uma versão mais recente de uma biblioteca, os nomes de nós podem ser alterados. As alterações de nome podem ser especificadas em um arquivo de migrações para que os gráficos criados em versões anteriores de uma biblioteca continuem a funcionar corretamente quando uma atualização é feita. As migrações são implementadas da seguinte maneira:

• Crie um arquivo .xml na mesma pasta que o .dll com o seguinte formato: “BaseDLLName”.Migrations.xml

• Em .xml, crie um único elemento <migrations>...</migrations>

• Dentro do elemento de migrações, crie os elementos <priorNameHint>...</priorNameHint> para cada alteração de nome

• Para cada alteração de nome, forneça um elemento <oldName>...</oldName> e <newName>...</newName>

1. Clicar com o botão direito do mouse e selecionar Add > New Item

2. Escolher XML File

3. Para este projeto, vamos nomear o arquivo de migrações ZeroTouchEssentials.Migrations.xml

Esse código de exemplo está informando ao Dynamo que qualquer nó denominado GetClosestPoint agora é nomeado ClosestPointTo.

<?xml version="1.0"?>
<migrations>
  <priorNameHint>
    <oldName>Autodesk.DesignScript.Geometry.Geometry.GetClosestPoint</oldName>
    <newName>Autodesk.DesignScript.Geometry.Geometry.ClosestPointTo</newName>
  </priorNameHint>
</migrations>

Consulte este exemplo de código em ProtoGeometry.Migrations.xml

Elementos genéricos

No momento, o recurso Sem toque não suporta o uso de elementos genéricos. Eles podem ser usados, mas não no código que é importado diretamente onde o tipo não está definido. Métodos, propriedades ou classes que são genéricos e não têm o conjunto de tipos não podem ser expostos.

No exemplo abaixo, um nó Sem toque do tipo T não será importado. Se o resto da biblioteca for importado para o Dynamo, haverá exceções de tipo ausentes.

public class SomeGenericClass<T>
{
    public SomeGenericClass()
    {
        Console.WriteLine(typeof(T).ToString());
    }  
}

O uso de um tipo genérico com o tipo definido neste exemplo será importado para o Dynamo.

public class SomeWrapper
{
    public object wrapped;
    public SomeWrapper(SomeGenericClass<double> someConstrainedType)
    {
        Console.WriteLine(this.wrapped.GetType().ToString());
    }
}

Introdução:

O Dynamo 2.0 é uma versão principal e algumas APIs foram alteradas ou removidas. Uma das maiores alterações que afetarão os autores de nó e pacote é a nossa mudança para um formato de arquivo JSON.

Em geral, os autores do nó Sem toque não terão muito trabalho a fazer para que os pacotes sejam executados na versão 2.0.

Os nós da interface do usuário e os nós que derivam diretamente do NodeModel exigirão mais trabalho para serem executados na versão 2.x.

Os autores da extensão também podem ter algumas alterações potenciais a serem feitas, dependendo de quanto das APIs principais do Dynamo eles usam em suas extensões.

Regras gerais de empacotamento:

• Não agrupe o Dynamo ou o Dynamo Revit .dlls com o pacote. Esses dlls já serão carregados pelo Dynamo. Se você agrupar uma versão diferente da que o usuário carregou _(ou seja, você distribui o dynamo core 1.3, mas o usuário está executando o pacote no dynamo 2.0) _, ocorrerão erros misteriosos de tempo de execução. Isso inclui dlls como DynamoCore.dll, DynamoServices.dll, DSCodeNodes.dll, ProtoGeometry.dll

• Não agrupe nem distribua o newtonsoft.json.net com o pacote se você puder evitá-lo. Esse dll também será carregado pelo Dynamo 2.x. O mesmo problema que acima pode ocorrer.

• Não agrupe nem distribua o CEFSharp com o pacote se você puder evitá-lo. Esse dll também será carregado pelo Dynamo 2.x. O mesmo problema que acima pode ocorrer.

• Em geral, evite compartilhar dependências com o Dynamo ou o Revit se precisar controlar a versão dessa dependência.

Problemas comuns:

1) Durante a abertura de um gráfico, alguns nós têm várias portas com o mesmo nome, mas o gráfico parecia correto ao salvar. Esse problema pode ter algumas causas.

A causa raiz comum é porque o nó foi criado usando um construtor que recriou as portas. Em vez disso, o construtor que carregou as portas deveria ter sido usado. Esses construtores são geralmente marcados [JsonConstructor]veja exemplos abaixo

Isso pode ocorrer porque:

• Não havia nenhum [JsonConstructor] correspondente ou ele não foi passado de Inports e Outports do .dyn JSON.

• Havia duas versões do JSON.net carregadas no mesmo processo ao mesmo tempo, causando falha de tempo de execução .net, de modo que o atributo [JsonConstructor] não podia ser usado corretamente para marcar o construtor.

• O DynamoServices.dll com uma versão diferente da versão atual do Dynamo foi fornecido com o pacote e está causando a falha do tempo de execução .net ao identificar o atributo [MultiReturn]; portanto, os nós Sem toque marcados com vários atributos não terão sido aplicados. Você pode descobrir que um nó retorna uma única saída de dicionário em vez de várias portas.

2) Os nós estão completamente ausentes ao carregar o gráfico com alguns erros no console.

• Isso pode ocorrer se a desserialização falhar por algum motivo. É uma boa prática serializar somente as propriedades que você precisa. Podemos usar [JsonIgnore] em propriedades complexas que não precisam ser carregadas ou salvas para serem ignoradas. Propriedades como function pointer, delegate, action, ou event etc. Elas não devem ser serializadas, pois normalmente falharão ao desserializar e causarão um erro de tempo de execução.

Atualização em profundidade:

Nós personalizados 1.3 -> 2.0

Organizar nós personalizados no arquivo librarie.js

Problemas conhecidos:

• Um nome de nó personalizado coincidente e um nome de categoria no mesmo nível no librarie.js causa um comportamento inesperado. QNTM-3653 – evite usar os mesmos nomes para a categoria e os nós.

• Os comentários serão transformados em comentários de bloco ao invés de comentários de linha.

• Nomes de tipo curto serão substituídos por nomes completos. Por exemplo, se você não especificou um tipo ao carregar o nó personalizado novamente, verá var[]..[] – pois esse é o tipo padrão.

Nós Sem toque 1.3 -> 2.0

• No Dynamo 2.0, os tipos Lista e Dicionário foram divididos e a sintaxe para a criação de listas e dicionários foi alterada. As listas são inicializadas usando [], enquanto os dicionários usam {}. Se você estava usando o atributo DefaultArgument anteriormente para marcar parâmetros nos nós sem toque e usou a sintaxe da lista para padronizar para uma lista específica como someFunc([DefaultArgument("{0,1,2}")]), isso não será mais válido e será necessário modificar o fragmento DesignScript para usar a nova sintaxe de inicialização das listas.

• Como observado acima, não distribua os dlls do Dynamo com os pacotes. (DynamoCore, DynamoServices etc.)

Nós do modelo de nós 1.3 -> 2.0

Os nós do modelo de nós são os que requerem mais trabalho para serem atualizados para o Dynamo 2.x. Em um nível alto, será necessário implementar construtores que serão usados somente para carregar os nós do json, além dos construtores nodeModel normais que são usados para instanciar novas instâncias dos tipos de nó. Para diferenciar entre esses, marque os construtores de tempo de carga com [JsonConstructor], que é um atributo de newtonsoft.Json.net.

Os nomes dos parâmetros no construtor devem normalmente coincidir com os nomes das propriedades JSON – embora esse mapeamento se torne mais complicado se você substituir os nomes que são serializados usando os atributos [JsonProperty]. Consulte a documentação do Json.net para obter mais informações.

Construtores JSON

A alteração mais comum necessária para atualizar nós derivados da classe base NodeModel (ou outras classes base do núcleo do Dynamo, ou seja, DSDropDownBase) é a necessidade de adicionar um construtor JSON à classe.

O construtor original sem parâmetros ainda lidará com a inicialização de um novo nó que é criado no Dynamo (por exemplo, através da biblioteca). O construtor JSON é necessário para inicializar um nó que é desserializado (carregado) de um arquivo .dyn ou .dyf salvo.

O construtor JSON difere do construtor base no fato de ter parâmetros PortModel para inPorts e outPorts, que são fornecidos pela lógica de carregamento JSON. A chamada para registrar as portas para o nó não é necessária aqui, pois os dados existem no arquivo .dyn. Um exemplo de construtor JSON se parece com isto:

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) { }

Esta sintaxe :base(Inports,outPorts){} chama o construtor base nodeModel e passa as portas desserializadas para ele.

Qualquer lógica especial que existisse no construtor de classe que envolva a inicialização de dados específicos que são serializados no arquivo .dyn (por exemplo, definir o registro de porta, estratégia de amarra, etc) não precisa ser repetida nesse construtor, pois esses valores podem ser lidos do JSON.

Essa é a principal diferença entre o construtor JSON e os construtores não JSON para os nodeModels. Os construtores JSON são chamados ao carregar de um arquivo e são passados os dados carregados. No entanto, outra lógica do usuário deve ser duplicada no construtor JSON (por exemplo, inicializando manipuladores de eventos para o nó ou anexando).

Exemplos podem ser encontrados aqui no repositório do DynamoSamples -> ButtonCustomNodeModel, DropDown ou SliderCustomNodeModel

Propriedades públicas e serialização

Anteriormente, um desenvolvedor podia serializar e desserializar dados de modelo específicos para o documento xml usando os métodos SerializeCore e DeserializeCore. Esses métodos ainda existem na API, mas serão obsoletos em uma versão futura do Dynamo (um exemplo pode ser encontrado aqui). Com a implementação do JSON.NET, agora as propriedades public na classe derivada NodeModel podem ser serializadas diretamente para o arquivo .dyn. O JSON.Net fornece vários atributos para controlar como a propriedade é serializada.

Esse exemplo que especifica um PropertyName é encontrado aqui no repositório do Dynamo.

[JsonProperty(PropertyName = "InputValue")]

public DSColor DsColor {...

Conversores:

Observação Se você criar sua própria classe de conversor JSON.net, o Dynamo não terá um mecanismo que permita injetá-la nos métodos de carregamento e salvamento e, portanto, mesmo que você marque a classe com o atributo [JsonConverter], ela poderá não ser usada. Em vez disso, você poderá chamar o conversor diretamente no configurador ou getter. //TODO precisa de confirmação dessa limitação. Qualquer evidência é bem-vinda.

Um exemplo que especifica um método de serialização para converter a propriedade em uma sequência de caracteres é encontrado aqui no repositório do Dynamo.

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

public ConversionMetricUnit SelectedMetricConversion{...

Ignorar as propriedades

As propriedades public que não são destinadas à serialização precisam ter o atributo [JsonIgnore] adicionado. Quando os nós são salvos no arquivo .dyn, isso garante que esses dados sejam ignorados pelo mecanismo de serialização e não causará consequências inesperadas quando o gráfico for aberto novamente. Um exemplo disso pode ser encontrado aqui no repositório do Dynamo.

Desfazer/Refazer

Como mencionado acima, os métodos SerializeCore e DeserializeCore foram usados no passado para salvar e carregar nós no arquivo xml .dyn. Além disso, eles também foram usados para salvar e carregar o estado do nó para desfazer/refazer e ainda são. Se você desejar implementar a funcionalidade desfazer/refazer complexa para o nó da interface do usuário nodeModel, será necessário implementar esses métodos e serializar no objeto de documento XML fornecido como um parâmetro para esses métodos. Esse deve ser um caso de uso raro, exceto para nós de interface do usuário complexos.

APIs de porta de entrada e saída

Uma ocorrência comum nos nós nodeModel afetados pelas alterações da API 2.0 é o registro de porta no construtor do nó. Observando exemplos no repositório do Dynamo ou DynamoSamples, você terá encontrado o uso dos métodos InPortData.Add() ou OutPortData.Add(). Anteriormente, na API do Dynamo, as propriedades InPortData e OutPortData públicas eram marcadas como obsoletas. Na versão 2.0, essas propriedades foram removidas. Os desenvolvedores agora devem usar os métodos InPorts.Add() e OutPorts.Add(). Além disso, esses dois métodos Add() têm assinaturas ligeiramente diferentes:

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

x

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

Exemplos de código convertido podem ser encontrados aqui no repositório do Dynamo -> DynamoConvert.cs ou FileSystem.cs

O outro caso de uso comum afetado pelas alterações da API 2.0 se relaciona aos métodos comumente usados no método BuildAst() para determinar o comportamento do nó com base na presença ou ausência de conectores de porta. Anteriormente, HasConnectedInput(index) era usado para validar um estado de porta conectada. Os desenvolvedores agora devem usar a propriedade InPorts[0].IsConnected para verificar o estado de conexão da porta. Um exemplo desse ícone pode ser encontrado em ColorRange.cs no repositório do Dynamo.

Exemplos:

Vamos passar pela atualização de um nó de interface do usuário 1.3 para o Dynamo 2.x.

using System;
using System.Collections.Generic;
using Dynamo.Graph.Nodes;
using CustomNodeModel.CustomNodeModelFunction;
using ProtoCore.AST.AssociativeAST;
using Autodesk.DesignScript.Geometry;

namespace CustomNodeModel.CustomNodeModel
{
    [NodeName("RectangularGrid")]
    [NodeDescription("An example NodeModel node that creates a rectangular grid. The slider randomly scales the cells.")]
    [NodeCategory("CustomNodeModel")]
    [InPortNames("xCount", "yCount")]
    [InPortTypes("double", "double")]
    [InPortDescriptions("Number of cells in the X direction", "Number of cells in the Y direction")]
    [OutPortNames("Rectangles")]
    [OutPortTypes("Autodesk.DesignScript.Geometry.Rectangle[]")]
    [OutPortDescriptions("A list of rectangles")]
    [IsDesignScriptCompatible]
    public class GridNodeModel : NodeModel
    {
        private double _sliderValue;
        public double SliderValue
        {
            get { return _sliderValue; }
            set
            {
                _sliderValue = value;
                RaisePropertyChanged("SliderValue");
                OnNodeModified(false);
            }
        }
        public GridNodeModel()
        {
            RegisterAllPorts();
        }
        public override IEnumerable<AssociativeNode> BuildOutputAst(List<AssociativeNode> inputAstNodes)
        {
            if (!HasConnectedInput(0) || !HasConnectedInput(1))
            {
                return new[] { AstFactory.BuildAssignment(GetAstIdentifierForOutputIndex(0), AstFactory.BuildNullNode()) };
            }
            var sliderValue = AstFactory.BuildDoubleNode(SliderValue);
            var functionCall =
              AstFactory.BuildFunctionCall(
                new Func<int, int, double, List<Rectangle>>(GridFunction.RectangularGrid),
                new List<AssociativeNode> { inputAstNodes[0], inputAstNodes[1], sliderValue });

            return new[] { AstFactory.BuildAssignment(GetAstIdentifierForOutputIndex(0), functionCall) };
        }
    }
}

Tudo o que precisamos fazer para esta classe nodeModel para que ela seja carregada e salva corretamente na versão 2.0 é adicionar um jsonConstructor para lidar com o carregamento das portas. Simplesmente passamos as portas no construtor base e essa implementação fica vazia.

[JsonConstructor]
protected GridNodeModel(IEnumerable<PortModel> Inports, IEnumerable<PortModel> Outports ) :
base(Inports,Outports)
{

}

Observação: Não chame RegisterPorts() ou alguma variação disso no JsonConstructor. Isso usará os atributos de parâmetro de entrada e saída na classe de nó para construir novas portas. Não queremos isso, pois queremos usar as portas carregadas que são passadas para o construtor.

[InPortNames("xCount", "yCount")]
[InPortTypes("double", "double")]

Este exemplo adiciona o construtor JSON de carga mínima possível. Mas e se precisarmos fazer uma lógica de construção mais complexa, como configurar alguns ouvintes para manipulação de eventos dentro do construtor? A próxima amostra obtida do Repositório do DynamoSamples está vinculada acima na JsonConstructors Section deste documento.

Aqui está um construtor mais complexo para um nó de interface do usuário:

 public ButtonCustomNodeModel()
        {
            // When you create a UI node, you need to do the
            // work of setting up the ports yourself. To do this,
            // you can populate the InPorts and the OutPorts
            // collections with PortData objects describing your ports.
            InPorts.Add(new PortModel(PortType.Input, this, new PortData("inputString", "a string value displayed on our button")));

            // Nodes can have an arbitrary number of inputs and outputs.
            // If you want more ports, just create more PortData objects.
            OutPorts.Add(new PortModel(PortType.Output, this, new PortData("button value", "returns the string value displayed on our button")));
            OutPorts.Add(new PortModel(PortType.Output, this, new PortData("window value", "returns the string value displayed in our window when button is pressed")));

            // This call is required to ensure that your ports are
            // properly created.
            RegisterAllPorts();

            // Listen for input port disconnection to trigger button UI update
            this.PortDisconnected += ButtonCustomNodeModel_PortDisconnected;

            // The arugment lacing is the way in which Dynamo handles
            // inputs of lists. If you don't want your node to
            // support argument lacing, you can set this to LacingStrategy.Disabled.
            ArgumentLacing = LacingStrategy.Disabled;

            // We create a DelegateCommand object which will be 
            // bound to our button in our custom UI. Clicking the button 
            // will call the ShowMessage method.
            ButtonCommand = new DelegateCommand(ShowMessage, CanShowMessage);

            // Setting our property here will trigger a 
            // property change notification and the UI 
            // will be updated to reflect the new value.
            ButtonText = defaultButtonText;
            WindowText = defaultWindowText;
        }

Quando adicionamos um construtor JSON para carregar esse nó de um arquivo, precisamos recriar parte dessa lógica, mas observe que não incluímos o código que cria portas, que define amarra ou que define os valores padrão para propriedades que podemos carregar do arquivo.

        // This constructor is called when opening a Json graph.

        [JsonConstructor]
        ButtonCustomNodeModel(IEnumerable<PortModel> inPorts, IEnumerable<PortModel> outPorts) : base(inPorts, outPorts)
        {
            this.PortDisconnected += ButtonCustomNodeModel_PortDisconnected;
            ButtonCommand = new DelegateCommand(ShowMessage, CanShowMessage);
        }

Observe que outras propriedades públicas que foram serializadas no JSON como ButtonText e WindowText não serão adicionadas como parâmetros explícitos ao construtor – elas são definidas automaticamente pelo JSON.net usando os definidores para essas propriedades.

Executar scripts Python em nós sem toque (C#)

Se você estiver familiarizado com a escrita de scripts no Python e desejar mais funcionalidade dos nós padrão do Dynamo Python, poderemos usar o recurso Sem toque para criar nossos próprios. Vamos começar com um exemplo simples que nos permite passar um script Python como uma sequência de caracteres para um nó Sem toque, onde o script é executado e um resultado é retornado. Este estudo de caso será baseado nos tutoriais virtuais e nos exemplos na seção Introdução. Consulte os exemplos se você for completamente novo na criação de nós Sem toque.

Um nó Sem toque que executará uma sequência de caracteres de script Python

Mecanismo Python

Esse nó depende de uma instância do mecanismo de scripts IronPython. Para fazer isso, precisamos fazer referência a algumas montagens adicionais. Siga as etapas abaixo para configurar um modelo básico no Visual Studio:

• Criar um novo projeto de classe do Visual Studio

• Adicionar uma referência ao IronPython.dll localizado em C:\Program Files (x86)\IronPython 2.7\IronPython.dll

• Adicionar uma referência ao Microsoft.Scripting.dll localizado em C:\Program Files (x86)\IronPython 2.7\Platforms\Net40\Microsoft.Scripting.dll

• Incluir as declarações IronPython.Hosting e Microsoft.Scripting.Hosting using na classe

• Adicionar um construtor vazio privado para evitar que um nó adicional seja adicionado à biblioteca do Dynamo com nosso pacote

• Criar um novo método que toma uma única sequência de caracteres como um parâmetro de entrada

• Dentro desse método, instanciaremos um novo mecanismo Python e criaremos um escopo de script vazio. Você pode imaginar esse escopo como as variáveis globais dentro de uma instância do interpretador Python

• Em seguida, chamar Execute no mecanismo que está passando a sequência de entrada e o escopo como parâmetros

• Por fim, recuperar e retornar os resultados do script chamando GetVariable no escopo e passando o nome da variável do script Python que contém o valor que você está tentando retornar. (Consulte o exemplo abaixo para obter detalhes adicionais)

O código a seguir fornece um exemplo para a etapa mencionada acima. A compilação da solução criará um novo .dll localizado na pasta bin de nosso projeto. Agora, é possível importar este .dll para o Dynamo como parte de um pacote ou navegar para File < Import Library...

using IronPython.Hosting;
using Microsoft.Scripting.Hosting;

namespace PythonLibrary
{
    public class PythonZT
    {
        // Unless a constructor is provided, Dynamo will automatically create one and add it to the library
        // To avoid this, create a private constructor
        private PythonZT() { }

        // The method that executes the Python string
        public static string executePyString(string pyString)
        {
            ScriptEngine engine = Python.CreateEngine();
            ScriptScope scope = engine.CreateScope();
            engine.Execute(pyString, scope);
            // Return the value of the 'output' variable from the Python script below
            var output = scope.GetVariable("output");
            return (output);
        }
    }
}

O script Python está retornando a variável output, o que significa que precisaremos de uma variável output no script Python. Use esse script de amostra para testar o nó no Dynamo. Se você já tiver usado o nó Python no Dynamo, o seguinte deverá ser familiar. Para obter mais informações, consulte a seção Python do manual.

import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *

cube = Cuboid.ByLengths(10,10,10);
volume = cube.Volume
output = str(volume)

Várias saídas

Uma limitação dos nós Python padrão é que eles têm somente uma única porta de saída, portanto, se desejarmos retornar vários objetos, deveremos criar uma lista e recuperar cada objeto. Se modificarmos o exemplo acima para retornar um dicionário, poderemos adicionar quantas portas de saída desejarmos. Consulte a seção Retornar vários valores em “Aprofundar o conhecimento sobre o nó Sem toque” para obter informações mais específicas sobre os dicionários.

Esse nó está nos permitindo retornar o volume do cuboide e seu centroide.

Vamos modificar o exemplo anterior com estas etapas:

• Adicionar uma referência ao DynamoServices.dll do gerenciador de pacotes do NuGet

• Além das montagens anteriores, incluir System.Collections.Generic e Autodesk.DesignScript.Runtime

• Modificar o tipo de retorno em nosso método para retornar um dicionário que conterá nossas saídas

• Cada saída deve ser individualmente recuperada do escopo (considere a possibilidade de configurar um loop simples para conjuntos maiores de saídas)

using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
using System.Collections.Generic;
using Autodesk.DesignScript.Runtime;

namespace PythonLibrary
{
    public class PythonZT
    {
        private PythonZT() { }

        [MultiReturn(new[] { "output1", "output2" })]
        public static Dictionary<string, object> executePyString(string pyString)
        {
            ScriptEngine engine = Python.CreateEngine();
            ScriptScope scope = engine.CreateScope();
            engine.Execute(pyString, scope);
            // Return the value of 'output1' from script
            var output1 = scope.GetVariable("output1");
            // Return the value of 'output2' from script
            var output2 = scope.GetVariable("output2");
            // Define the names of outputs and the objects to return
            return new Dictionary<string, object> {
                { "output1", (output1) },
                { "output2", (output2) }
            };
        }
    }
}

Também adicionamos uma variável de saída (output2) ao script python de amostra. Lembre-se de que essas variáveis podem usar qualquer convenção de nomenclatura Python legal, a saída foi usada estritamente para fins de clareza neste exemplo.

import clr
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *

cube = Cuboid.ByLengths(10,10,10);
centroid = Cuboid.Centroid(cube);
volume = cube.Volume
output1 = str(volume)
output2 = str(centroid)

Os nós baseados no NodeModel fornecem significativamente mais flexibilidade e potência do que os nós Sem toque. Neste exemplo, levaremos o nó de grade Sem toque para o próximo nível ao adicionar um controle deslizante integrado que randomiza o tamanho do retângulo.

O controle deslizante dimensiona as células em relação a seu tamanho, de modo que o usuário não precise fornecer um controle deslizante com o intervalo correto.

Padrão “Model-View-Viewmodel”

Em um alto nível, há duas partes para estabelecer uma relação de vista de modelo no Dynamo:

• Uma classe NodeModel para estabelecer a lógica central do nó (o “modelo”)

• Uma classe INodeViewCustomization para personalizar como o NodeModel está sendo visualizado (a “vista”)

Os objetos NodeModel já têm um modelo de vista associado (NodeViewModel), portanto, podemos nos concentrar no modelo e na vista para a interface do usuário personalizada.

Como implementar o NodeModel

Os nós NodeModel têm diversas diferenças significativas dos nós Sem toque que abordaremos neste exemplo. Antes de passarmos para a personalização da interface do usuário, vamos começar compilando a lógica do NodeModel.

1. Criar a estrutura do projeto:

Um nó NodeModel pode chamar somente funções, portanto, precisamos separar o NodeModel e as funções em diferentes bibliotecas. A forma padrão de fazer isso para pacotes do Dynamo é criar projetos separados para cada um. Comece criando uma nova solução para englobar os projetos.

1. Selecionar File > New > Project

2. Selecionar Other Project Types para ativar a opção Solução

3. Selecionar Blank Solution

4. Nomear a solução CustomNodeModel

5. Selecionar Ok

Crie dois projetos de biblioteca de classes C# na solução: um para as funções e outro para implementar a interface NodeModel.

1. Clicar com o botão direito do mouse na Solução e selecionar Add > New Project

2. Escolher a biblioteca de classes

3. Nomeá-la CustomNodeModel

4. Clicar em Ok

5. Repita o processo para adicionar outro projeto nomeado CustomNodeModelFunctions

Em seguida, precisamos renomear as bibliotecas de classes que foram criadas automaticamente e adicionar uma ao projeto CustomNodeModel. A classe GridNodeModel implementa a classe NodeModel abstrata, GridNodeView é usada para personalizar a vista e GridFunction contém as funções que precisamos chamar.

1. Adicionar outra classe clicando com o botão direito do mouse no projeto CustomNodeModel, selecionando Add > New Item... e escolhendo Class.

2. No projeto CustomNodeModel, precisamos das classes GridNodeModel.cs e GridNodeView.cs

3. No projeto CustomNodeModelFunction, precisamos de uma classe GridFunctions.cs

Antes de adicionarmos qualquer código às classes, adicione os pacotes necessários para este projeto. CustomNodeModel precisará de ZeroTouchLibrary e WpfUILibrary e CustomNodeModelFunction só precisará de ZeroTouchLibrary. A biblioteca WpfUIL será usada na personalização da interface do usuário que faremos mais tarde, e a biblioteca ZeroTouchLibrary será usada para criar a geometria. É possível adicionar os pacotes individualmente para os projetos. Como esses pacotes têm dependências, o Core e o DynamoServices serão instalados automaticamente.

1. Clicar com o botão direito do mouse em um projeto e selecionar Manage NuGet Packages

2. Instalar somente os pacotes necessários para aquele projeto

O Visual Studio copiará os pacotes NuGet aos quais fizemos referência para o diretório de compilação. Isso pode ser definido como false, para que não tenhamos arquivos desnecessários no pacote.

1. Selecionar pacotes do Dynamo NuGet

2. Definir Copy Local como false

2. Herdar a classe NodeModel

Como mencionado anteriormente, o aspecto principal que torna um nó NodeModel diferente de um nó Sem toque é a implementação da classe NodeModel. Um nó NodeModel precisa de diversas funções dessa classe, e podemos obtê-las adicionando :NodeModel após o nome da classe.

Copie o seguinte código para o GridNodeModel.cs.

Isso é diferente dos nós Sem toque. Vamos entender o que cada parte está fazendo.

• Especificar os atributos do nó, como nomes Name, Category, InPort/OutPort, tipos InPort/OutPort e descrições.

• public class GridNodeModel : NodeModel é uma classe que herda a classe NodeModel de Dynamo.Graph.Nodes.

• public GridNodeModel() { RegisterAllPorts(); } é um construtor que registra as entradas e saídas do nó.

• BuildOutputAst() retorna um AST (Abstract Syntax Tree), a estrutura necessária para retornar os dados de um nó NodeModel.

• AstFactory.BuildFunctionCall() chama a função RetangularGrid de GridFunctions.cs.

• new Func<int, int, double, List<Rectangle>>(GridFunction.RectangularGrid) especifica a função e seus parâmetros.

• new List<AssociativeNode> { inputAstNodes[0], inputAstNodes[1], sliderValue }); mapeia as entradas do nó para parâmetros de função

• AstFactory.BuildNullNode() compilará um nó nulo se as portas de entrada não estiverem conectadas. Isso é para evitar a exibição de um aviso no nó.

• RaisePropertyChanged("SliderValue") notifica a interface do usuário quando o valor do controle deslizante é alterado

• var sliderValue = AstFactory.BuildDoubleNode(SliderValue) compila um nó no AST que representa o valor do controle deslizante

• Alterar uma entrada para a variável sliderValue na variável functionCall new List<AssociativeNode> { inputAstNodes[0], sliderValue });

3. Chamar uma função

O projeto CustomNodeModelFunction será compilado em uma montagem separada de CustomNodeModel para que possa ser chamado.

Copie o seguinte código para GridFunction.cs.

Essa classe de função é muito similar ao estudo de caso de Grade sem Toque, com uma diferença:

• [IsVisibleInDynamoLibrary(false)] impede que o Dynamo “veja” o seguinte método e classe, já que a função já está sendo chamada de CustomNodeModel.

Assim como adicionamos referências para pacotes NuGet, CustomNodeModel precisará fazer referência a CustomNodeModelFunction para chamar a função.

A declaração de uso para CustomNodeModel estará inativa até que a função seja referenciada

1. Clicar com o botão direito do mouse em CustomNodeModel e selecionar Add > Reference

2. Escolher Projects > Solution

3. Marcar CustomNodeModelFunction

4. Clicar em Ok

4. Personalizar a vista

Para criar um controle deslizante, é preciso personalizar a interface do usuário implementando a interface do INodeViewCustomization.

Copie o seguinte código para GridNodeView.cs

• public class CustomNodeModelView : INodeViewCustomization<GridNodeModel> define as funções necessárias para personalizar a interface do usuário.

Após a estrutura do projeto ter sido configurada, use o ambiente de projeto do Visual Studio para compilar um controle de usuário e definir seus parâmetros em um arquivo .xaml. Na caixa de ferramentas, adicione um controle deslizante a <Grid>...</Grid>.

1. Clicar com o botão direito do mouse em CustomNodeModel e selecionar Add > New Item

2. Selecionar WPF

3. Nomear o controle de usuário Slider

4. Clicar em Add

Copie o seguinte código para Slider.xaml

• Os parâmetros do controle deslizante são definidos no arquivo .xaml. Os atributos Mínimo e Máximo definem o intervalo numérico dessa barra deslizante.

• Dentro de <Grid>...</Grid>, podemos colocar diferentes controles de usuário na caixa de ferramentas do Visual Studio

Quando criamos o arquivo Slider.xaml, o Visual Studio criou automaticamente um arquivo C# chamado Slider.xaml.cs que inicializa o controle deslizante. Altere o namespace nesse arquivo.

• O namespace deve ser CustomNodeModel.CustomNodeModel

O GridNodeModel.cs define a lógica de cálculo do controle deslizante.

5. Configurar como um pacote

Antes de compilarmos o projeto, a etapa final é adicionar um arquivo pkg.json para que o Dynamo possa ler o pacote.

1. Clicar com o botão direito do mouse em CustomNodeModel e selecionar Add > New Item

2. Selecionar Web

3. Selecionar JSON File

4. Nomear o arquivo pkg.json

5. Clicar em Add

• Copie o seguinte código para pkg.json

• "name": determina o nome do pacote e seu grupo na biblioteca do Dynamo

• "keywords": fornece termos de pesquisa para pesquisar na biblioteca do Dynamo

• "node_libraries": [] as bibliotecas associadas ao pacote

  A última etapa é compilar a solução e publicar como um pacote do Dynamo. Consulte o capítulo Implantação do pacote para saber como criar um pacote local antes de publicar on-line e como compilar um pacote diretamente do Visual Studio.

As extensões são uma poderosa ferramenta de desenvolvimento no ecossistema do Dynamo. Elas permitem que os desenvolvedores direcionem a funcionalidade personalizada com base nas interações e lógica do Dynamo. As extensões podem ser divididas em duas categorias principais, extensões e extensões de vista. Como a nomenclatura indica, a estrutura de extensão da vista permite estender a interface do usuário do Dynamo registrando itens de menu personalizados. As extensões regulares operam de forma muito semelhante, exceto a interface do usuário. Por exemplo, podemos compilar uma extensão que registra informações específicas no console do Dynamo. Esse cenário não requer uma interface do usuário personalizada e, portanto, também pode ser realizado usando uma extensão.

Estudo de caso de extensão

Seguindo o exemplo SampleViewExtension do repositório Github do DynamoSamples, vamos percorrer as etapas necessárias para criar uma janela simples sem janela restrita que exibe os nós ativos no gráfico em tempo real. Uma extensão de vista requer que criemos uma interface do usuário para a janela e vinculemos valores a um modelo de vista.

1. A janela de extensão da vista foi desenvolvida seguindo o exemplo SampleViewExtension no repositório Github.

Embora possamos compilar o exemplo desde o início, também é possível fazer o download e criar o repositório DynamoSamples para servir como referência.

Repositório DynamoSamples: https://github.com/DynamoDS/DynamoSamples

Este percurso virtual fará referência específica ao projeto denominado SampleViewExtension encontrado em DynamoSamples/src/.

Como implementar uma extensão de vista

Uma extensão de vista tem três partes essenciais:

• Uma montagem contendo uma classe que implementa IViewExtension, bem como uma classe que cria um modelo de vista

• Um arquivo .xml que informa ao Dynamo onde ele deve procurar por essa montagem no tempo de execução e o tipo de extensão

• Um arquivo .xaml que vincula os dados à exibição gráfica e determina a aparência da janela

1. Criar a estrutura do projeto

Comece criando um novo projeto Class Library chamado SampleViewExtension.

1. Criar um novo projeto selecionando File > New > Project

2. Selecionar Class Library

3. Nomear o projeto SampleViewExtension

4. Selecionar Ok

Neste projeto, precisaremos de duas classes. Uma classe implementará IViewExtension e a outra que implementará NotificationObject. IViewExtension conterá todas as informações sobre como nossa extensão será implantada, carregada, referenciada e eliminada. NotificationObject fornecerá notificações de alterações no Dynamo e IDisposable quando ocorrer uma alteração, a contagem será atualizada de acordo.

1. Um arquivo de classe denominado SampleViewExtension.cs que implementará IViewExtension

2. Um arquivo de classe denominado SampleWindowViewMode.cs que implementará NotificationObject

Para usar o IViewExtension, precisaremos do pacote WpfUILibrary NuGet. A instalação desse pacote instalará automaticamente os pacotes Core, Services e ZeroTouchLibrary.

1. Selecionar a biblioteca WpfUIL

2. Selecionar Install para instalar todos os pacotes dependentes

2. Implementar a classe IViewExtension

Na classe IViewExtension, vamos determinar o que acontece quando o Dynamo é iniciado, quando a extensão é carregada e quando o Dynamo é fechado. No arquivo de classe SampleViewExtension.cs, adicione o seguinte código:

using System;
using System.Windows;
using System.Windows.Controls;
using Dynamo.Wpf.Extensions;

namespace SampleViewExtension
{

    public class SampleViewExtension : IViewExtension
    {
        private MenuItem sampleMenuItem;

        public void Dispose()
        {
        }

        public void Startup(ViewStartupParams p)
        {
        }

        public void Loaded(ViewLoadedParams p)
        {
            // Save a reference to your loaded parameters.
            // You'll need these later when you want to use
            // the supplied workspaces

            sampleMenuItem = new MenuItem {Header = "Show View Extension Sample Window"};
            sampleMenuItem.Click += (sender, args) =>
            {
                var viewModel = new SampleWindowViewModel(p);
                var window = new SampleWindow
                {
                    // Set the data context for the main grid in the window.
                    MainGrid = { DataContext = viewModel },

                    // Set the owner of the window to the Dynamo window.
                    Owner = p.DynamoWindow
                };

                window.Left = window.Owner.Left + 400;
                window.Top = window.Owner.Top + 200;

                // Show a modeless window.
                window.Show();
            };
            p.AddMenuItem(MenuBarType.View, sampleMenuItem);
        }

        public void Shutdown()
        {
        }

        public string UniqueId
        {
            get
            {
                return Guid.NewGuid().ToString();
            }  
        } 

        public string Name
        {
            get
            {
                return "Sample View Extension";
            }
        } 

    }
}

A classe SampleViewExtension cria um item de menu clicável para abrir a janela e conecta-a ao modelo de vista e à janela.

• public class SampleViewExtension : IViewExtension SampleViewExtension herda da interface do IViewExtension e fornece tudo o que precisamos para criar o item de menu.

• sampleMenuItem = new MenuItem { Header = "Show View Extension Sample Window" }; cria um MenuItem e o adiciona ao menu View.

1. O item de menu

• sampleMenuItem.Click += (sender, args) aciona um evento que abrirá uma nova janela quando o item de menu for clicado

• MainGrid = { DataContext = viewModel } define o contexto de dados para a grade principal na janela, referindo-se a Main Grid no arquivo .xaml que criaremos

• Owner = p.DynamoWindow define o proprietário da janela pop-out como Dynamo. Isso significa que a nova janela depende do Dynamo, portanto, ações como minimizar, maximizar e restaurar o Dynamo farão com que a nova janela siga esse mesmo comportamento

• window.Show(); exibe a janela onde as propriedades adicionais da janela foram definidas

3. Implementar o modelo de vista

Agora que estabelecemos alguns dos parâmetros básicos da janela, adicionaremos a lógica para responder a vários eventos relacionados ao Dynamo e instruiremos a interface do usuário a atualizar com base nesses eventos. Copie o seguinte código para o arquivo de classe SampleWindowViewModel.cs:

using System;
using Dynamo.Core;
using Dynamo.Extensions;
using Dynamo.Graph.Nodes;

namespace SampleViewExtension
{
    public class SampleWindowViewModel : NotificationObject, IDisposable
    {
        private string activeNodeTypes;
        private ReadyParams readyParams;

        // Displays active nodes in the workspace
        public string ActiveNodeTypes
        {
            get
            {
                activeNodeTypes = getNodeTypes();
                return activeNodeTypes;
            }
        }

        // Helper function that builds string of active nodes
        public string getNodeTypes()
        {
            string output = "Active nodes:\n";

            foreach (NodeModel node in readyParams.CurrentWorkspaceModel.Nodes)
            {
                string nickName = node.Name;
                output += nickName + "\n";
            }

            return output;
        }

        public SampleWindowViewModel(ReadyParams p)
        {
            readyParams = p;
            p.CurrentWorkspaceModel.NodeAdded += CurrentWorkspaceModel_NodesChanged;
            p.CurrentWorkspaceModel.NodeRemoved += CurrentWorkspaceModel_NodesChanged;
        }

        private void CurrentWorkspaceModel_NodesChanged(NodeModel obj)
        {
            RaisePropertyChanged("ActiveNodeTypes");
        }

        public void Dispose()
        {
            readyParams.CurrentWorkspaceModel.NodeAdded -= CurrentWorkspaceModel_NodesChanged;
            readyParams.CurrentWorkspaceModel.NodeRemoved -= CurrentWorkspaceModel_NodesChanged;
        }
    }
}

Essa implementação da classe de modelo de vista ouve o CurrentWorkspaceModel e aciona um evento quando um nó é adicionado ou removido do espaço de trabalho. Isso gera uma alteração de propriedade que notifica a interface do usuário ou elementos vinculados que os dados foram alterados e precisam ser atualizados. O getter ActiveNodeTypes é chamado, o que chama internamente uma função getNodeTypes() de ajuda adicional. Essa função interage em todos os nós ativos na tela, preenche uma sequência de caracteres contendo os nomes desses nós e retorna essa sequência para nossa associação no arquivo .xaml para ser exibido em nossa janela pop-out.

Com a lógica principal da extensão definida, agora vamos especificar os detalhes de aparência da janela com um arquivo .xaml. Tudo que precisamos é uma janela simples que exiba a sequência de caracteres usando a associação de propriedade ActiveNodeTypes noTextBlock Text.

1. Clicar com o botão direito do mouse no projeto e selecionar Add > New Item...

2. Selecionar o modelo Controle de usuário que vamos alterar para criar uma janela

3. Nomear o novo arquivo SampleWindow.xaml

4. Selecionar Add

No código da janela .xaml, precisaremos vincular SelectedNodesText a um bloco de texto. Adicione o seguinte código a SampleWindow.xaml:

<Window x:Class="SampleViewExtension.SampleWindow"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             xmlns:local="clr-namespace:SampleViewExtension"
             mc:Ignorable="d" 
             d:DesignHeight="300" d:DesignWidth="300"
            Width="500" Height="100">
    <Grid Name="MainGrid" 
          HorizontalAlignment="Stretch"
          VerticalAlignment="Stretch">
        <TextBlock HorizontalAlignment="Stretch" Text="{Binding ActiveNodeTypes}" FontFamily="Arial" Padding="10" FontWeight="Medium" FontSize="18" Background="#2d2d2d" Foreground="White"/>
    </Grid>
</Window>

• Text="{Binding ActiveNodeTypes}" vincula o valor da propriedade de ActiveNodeTypes em SampleWindowViewModel.cs ao valor TextBlock Text na janela.

Agora, inicializaremos a janela de amostra no arquivo de backup .xaml C# SampleWindow.xaml.cs. Adicione o seguinte código a SampleWindow.xaml:

using System.Windows;

namespace SampleViewExtension
{
    /// <summary>
    /// Interaction logic for SampleWindow.xaml
    /// </summary>
    public partial class SampleWindow : Window
    {
        public SampleWindow()
        {
            InitializeComponent();
        }
    }
}

A extensão da vista agora está pronta para ser criada e adicionada ao Dynamo. O Dynamo requer um arquivo xml para registrar nossa saída .dll como uma extensão.

1. Clicar com o botão direito do mouse no projeto e selecionar Add > New Item...

2. Selecionar o arquivo XML

3. Nomear o arquivo SampleViewExtension_ViewExtensionDefinition.xml

4. Selecionar Add

• O nome do arquivo segue a norma do Dynamo para fazer referência a uma montagem de extensão como esta: "extensionName"_ViewExtensionDefinition.xml

No arquivo xml, adicione o seguinte código para informar ao Dynamo onde procurar a montagem de extensão:

<ViewExtensionDefinition>
  <AssemblyPath>C:\Users\username\Documents\Visual Studio 2015\Projects\SampleViewExtension\SampleViewExtension\bin\Debug\SampleViewExtension.dll</AssemblyPath>
  <TypeName>SampleViewExtension.SampleViewExtension</TypeName>
</ViewExtensionDefinition>

• Neste exemplo, compilamos a montagem na pasta de projeto padrão do Visual Studio. Substitua o destino <AssemblyPath>...</AssemblyPath> pela localização da montagem.

A última etapa é copiar o arquivo SampleViewExtension_ViewExtensionDefinition.xml para a pasta de extensões de vista do Dynamo localizada no diretório de instalação C:\Program Files\Dynamo\Dynamo Core\1.3\viewExtensions do Dynamo Core. É importante observar que há pastas separadas para extensions e viewExtensions. Colocar o arquivo xml na pasta incorreta pode causar falha ao carregar corretamente no tempo de execução.

1. O arquivo .xml que copiamos para a pasta de extensões de vista do Dynamo

Esta é uma introdução básica às extensões da vista. Para um estudo de caso mais sofisticado, consulte o pacote DynaShape, um projeto de código aberto no Github. O pacote usa uma extensão de vista que permite a edição ao vivo na vista do modelo do Dynamo.

É possível fazer o download de um instalador de pacote para o DynamoShape do Fórum do Dynamo: https://forum.dynamobim.com/t/dynashape-published/11666

O código-fonte pode ser clonado do Github: https://github.com/LongNguyenP/DynaShape

Com um projeto do Visual Studio ativo e em execução, vamos analisar como compilar um nó personalizado que cria uma grade retangular de células. Embora possamos criar isso com vários nós padrão, é uma ferramenta útil que pode ser facilmente contida em um nó Sem toque. Ao contrário das linhas de grade, as células podem ser dimensionadas em torno de seus pontos centrais, consultadas para seus vértices de canto ou incorporadas em faces.

Este exemplo abordará alguns dos recursos e conceitos a serem considerados ao criar um nó Sem toque. Depois de compilarmos o nó personalizado e adicioná-lo ao Dynamo, verifique se a página “Aprofundar o conhecimento sobre o nó Sem Toque” fornece uma visão mais profunda dos valores de entrada padrão, retornando vários valores, documentação, objetos, usando tipos de geometria do Dynamo e migrações.

Nó de grade retangular personalizado

Para começar a compilar o nó de grade, crie um novo projeto de biblioteca de classes do Visual Studio. Consulte a página Introdução para obter uma visão geral detalhada de como configurar um projeto.

1. Escolher Class Library para o tipo de projeto

2. Nomear o projeto CustomNodes

Como vamos criar geometria, precisamos fazer referência ao pacote NuGet apropriado. Instale o pacote ZeroTouchLibrary do Gerenciador de pacotes Nuget. Esse pacote é necessário para a declaração using Autodesk.DesignScript.Geometry;.

1. Procure o pacote ZeroTouchLibrary

2. Usaremos esse nó na compilação atual do Dynamo Studio, que é 1.3. Selecione a versão do pacote que corresponde a isso.

3. Observe que também renomeamos o arquivo de classe para Grids.cs

Em seguida, precisamos estabelecer um namespace e uma classe na qual o método RetangularGrid residirá. O nó será nomeado no Dynamo de acordo com o método e os nomes de classe. Ainda não precisamos copiar isso no Visual Studio.

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; faz referência ao arquivo ProtoGeometry.dll no pacote ZeroTouchLibrary System.Collections.Generic, que é necessário para criar listas

Agora podemos adicionar o método para desenhar os retângulos. O arquivo de classe deve ter este aspecto e pode ser copiado para o 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;
        }
    }
}

Se o projeto for semelhante a este, vá em frente e tente compilar o .dll.

1. Escolher Compilar > Compilar solução

Verifique a pasta bin do projeto para obter um .dll. Se a compilação tiver sido bem-sucedida, poderemos adicionar o .dll ao Dynamo.

1. O nó personalizado RectangularGrids na Biblioteca do Dynamo

2. O nó personalizado na tela

3. O botão Adicionar para adicionar o .dll ao Dynamo

Modificações de nós personalizados

No exemplo acima, criamos um nó bastante simples que não definiu muito mais fora do método RectangularGrids. No entanto, podemos desejar criar dicas de ferramentas para portas de entrada ou fornecer ao nó um resumo, como os nós padrão do Dynamo. Adicionar esses recursos a nós personalizados facilita seu uso, especialmente se um usuário desejar pesquisá-los na biblioteca.

1. Um valor de entrada padrão

2. Uma dica de ferramenta para a entrada xCount

O nó RetangularGrid precisa de alguns desses recursos básicos. No código abaixo, adicionamos descrições de porta de entrada e saída, um resumo e valores de entrada padrão.

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;
        }
    }
}

• Forneça os valores padrão das entradas atribuindo valores aos parâmetros do método: RectangularGrid(int xCount = 10, int yCount = 10)

• Crie dicas de ferramentas de entrada e saída, palavras-chave de pesquisa e um resumo com a documentação XML precedida por ///.

Para adicionar dicas de ferramentas, precisamos de um arquivo xml no diretório do projeto. É possível gerar um .xml automaticamente pelo Visual Studio ativando a opção.

1. Ative o arquivo de documentação XML aqui e especifique um caminho de arquivo. Isso gera um arquivo XML.

E pronto. Criamos um novo nó com vários recursos padrão. O capítulo a seguir, “Noções básicas sobre o nó Sem toque”, entra em mais detalhes sobre o desenvolvimento do nó Sem toque e os problemas dos quais você deve estar ciente.