-o, -O, --OpenFilePath Instrua o Dynamo a abrir um arquivo de comando e execute os comandos contidos no caminho. Essa opção só é suportada quando executada no DynamoSandbox.

-c, -C, --CommandFilePath Instrua o Dynamo a abrir um arquivo de comando e execute os comandos contidos no caminho. Essa opção só é suportada quando executada no DynamoSandbox.

-v, -V, --Verbose Instrua o Dynamo a enviar todas as avaliações que executa para um arquivo XML no caminho especificado.

-g, -G, --Geometry Instrua o Dynamo a gerar a geometria de todas as avaliações para um arquivo JSON nesse caminho.

-h, -H, --help Obtenha ajuda.

-i, -I, --Import Instrua o Dynamo a importar uma montagem como uma biblioteca de nós. Esse argumento deve ser um caminho de arquivo para um único .dll. Se você deseja importar vários .dlls, liste-os separados por um espaço: -i 'assembly1.dll' 'assembly2.dll'.

--GeometryPath Caminho relativo ou absoluto para um diretório que contém o ASM. Quando fornecido, em vez de procurar o ASM no disco rígido, ele será carregado diretamente desse caminho.

-k, -K, --KeepAlive Modo Keepalive, deixe o processo do Dynamo em execução até que uma extensão carregada o desligue.

--HostName Identifique a variação do Dynamo associada ao hospedeiro.

-s, -S, --SessionId Identifique a ID da sessão de análise do hospedeiro do Dynamo.

-p, -P, --ParentId Identifique a ID pai da análise do hospedeiro do Dynamo.

-x, -X, --ConvertFile Quando usado em combinação com o indicador -O, abre um arquivo .dyn no caminho especificado e o converte em .json. O arquivo terá a extensão .json e estará localizado no mesmo diretório que o arquivo original.

-n, -N, --NoConsole Não confie na janela do console para interagir com a CLI no modo Keepalive.

-u, -U, --UserData Especifique a pasta de dados do usuário a ser usada pelo PathResolver com a CLI.

--CommonData Especifique a pasta de dados comuns a ser usada pelo PathResolver com a CLI.

--DisableAnalytics Desativa a análise no Dynamo durante a vida útil do processo.

--CERLocation Especifique a ferramenta de relatório de erros fatais localizada no disco.

--ServiceMode Especifique a inicialização do modo de serviço.

Por quê

Você pode querer controlar o Dynamo por meio da linha de comando por vários motivos, como:

• Automatizar muitas execuções do Dynamo

• Testar os gráficos do Dynamo (veja também -c quando usar o DynamoSandbox)

• Executar uma sequência de gráficos do Dynamo em uma ordem específica

• Escrever arquivos em lote que executam várias execuções de linha de comando

O quê

A interface de linha de comando (DynamoCLI) é um suplemento do DynamoSandbox. É um utilitário de linha de comando dos/terminal desenvolvido para fornecer a conveniência de argumentos de linha de comando para executar o Dynamo. Em sua primeira implementação, ela não é executada de forma independente, deve ser executada da pasta onde os binários do Dynamo residem, pois depende das mesmas DLLs principais do Sandbox. Ela não pode interoperar com outras compilações do Dynamo.

Há quatro formas de executar a CLI: em um prompt do Dos, de arquivos em lote do Dos e como um atalho na área de trabalho do Windows cujo caminho é modificado para incluir os indicadores de linha de comando especificados. A especificação do arquivo Dos pode ser totalmente qualificada ou relativa, e as unidades mapeadas e a sintaxe da URL também são suportadas. Ela também pode ser construída com o Mono e ser executada em Linux ou Mac no terminal.

Os pacotes Dynamo são suportados pelo utilitário. No entanto, não é possível carregar nós personalizados (dyf), apenas gráficos independentes (dyn).

Em testes preliminares, o utilitário da CLI oferece suporte a versões localizadas do Windows e é possível especificar argumentos filespec com caracteres Ascii superiores.

A CLI pode ser acessada por meio do aplicativo DynamoCLI.exe. Esse aplicativo permite que um usuário ou outro aplicativo interaja com o modelo de avaliação do Dynamo invocando o DynamoCLI.exe com uma sequência de caracteres de comandos. Isso pode ser algo assim:

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe -o "C:\someReallyCoolDynamoFile.Dyn"

Esse comando dirá ao Dynamo para abrir o arquivo especificado em “C:\someReallyCoolDynamoFile.Dyn”, sem desenhar nenhuma IU, e executá-lo. O Dynamo será encerrado quando a execução do gráfico for concluída.

Novo na versão 2.1: o aplicativo DynamoWPFCLI.exe. Esse aplicativo suporta tudo o que o aplicativo DynamoCLI.exe suporta com a adição da opção Geometria (-g). O aplicativo DynamoWPFCLI.exe está disponível somente para Windows.

Observações importantes

• O método preferido de interação com o DynamoCLI é por meio de uma interface de prompt do comando.

• Neste momento, será necessário executar o DynamoCLI da localização de instalação dentro da pasta [Versão do Dynamo]. A CLI precisa acessar os mesmos .dlls que o Dynamo, então ela não deve ser movida.

• Você deverá ser capaz de executar os gráficos que estão atualmente abertos no Dynamo, mas isso poderá causar efeitos colaterais indesejados.

• Todos os caminhos de arquivo são totalmente compatíveis com DOS. Portanto, os caminhos relativos e totalmente qualificados devem funcionar, mas certifique-se de colocar os caminhos entre aspas

Como

-o é possível abrir o Dynamo apontando para um .dyn, em um modo headless que executará o gráfico.

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe -o "C:\someReallyCoolDynamoFile.Dyn"

-v pode ser usado quando o Dynamo estiver sendo executado em modo headless (quando usamos -o para abrir um arquivo). Esse indicador iterará todos os nós no gráfico e despejará seus valores de saída em um arquivo XML simples. Como o indicador --ServiceMode pode forçar o Dynamo a executar várias avaliações de gráfico, o arquivo de saída conterá valores para cada avaliação que ocorrer.

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe -o "C:\someReallyCoolDynamoFile.Dyn" -p "C:\aFileWithPresetsInIt.dyn" --ServiceMode "all" -v "C:\output.xml"

O arquivo de saída XML teria o formato a seguir:

-g pode ser usado quando o Dynamo estiver sendo executado em modo headless (quando usamos -o para abrir um arquivo). Esse indicador gerará o gráfico e despejará a geometria resultante em um arquivo JSON.

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoWPFCLI.exe -o "C:\someReallyCoolDynamoFile.Dyn" -g "C:\geometry.json"

O arquivo de geometria JSON teria o formato a seguir:

TBD – Trabalho em andamento

-h use essa opção para obter uma lista das possíveis opções

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe -h

o indicador -i pode ser usado várias vezes para importar várias montagens que o gráfico que você está tentando abrir precisa para ser executado.

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe -o "C:\someReallyCoolDynamoFile.Dyn" -i"a.dll" -i"aSecond.dll"

o indicador -l pode ser usado para executar o Dynamo em uma configuração de localidade diferente. Mas, geralmente, a configuração de localidade não afeta os resultados do gráfico

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe -o "C:\someReallyCoolDynamoFile.Dyn" -l "de-DE"

o indicador --GeometryPath pode ser usado para apontar o DynamoSandbox ou a CLI para um conjunto específico de binários ASM. Use-o como

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoSandbox.exe --GeometryPath "\pathToGeometryBinaries\"

ou

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoSandbox.exe --GeometryPath "\pathToGeometryBinaries\"

o indicador -k pode ser usado para deixar o processo do Dynamo em execução até que uma extensão carregada o desligue.

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe -k

o indicador --HostName pode ser usado para identificar a variação do Dynamo associada ao hospedeiro.

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe --HostName "DynamoFormIt"

ou

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoSandbox.exe --HostName "DynamoFormIt"

o indicador -s pode ser usado para identificar a ID da sessão de análise do hospedeiro do Dynamo

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe -s [HostSessionId]

o indicador -p pode ser usado para identificar a ID pai da análise do hospedeiro do Dynamo

C:\Program Files\Dynamo\Dynamo Core\[Dynamo Version]\DynamoCLI.exe -p "RVT&2022&MUI64&22.0.2.392"

Publicar um pacote

Os pacotes são uma forma conveniente de armazenar e compartilhar nós com a comunidade do Dynamo. Um pacote pode conter tudo, desde nós personalizados criados no espaço de trabalho do Dynamo até nós derivados do NodeModel. Os pacotes são publicados e instalados usando o Gerenciador de pacotes. Além desta página, o Manual tem um guia geral sobre os pacotes.

O que é um Gerenciador de pacotes?

O Gerenciador de pacotes do Dynamo é um Registro de software (semelhante ao npm) que pode ser acessado no Dynamo ou em um navegador da Web. O Gerenciador de pacotes inclui a instalação, publicação, atualização e visualização de pacotes. Como o npm, ele mantém diferentes versões de pacotes. Também ajuda a gerenciar as dependências do projeto.

No navegador, procure pacotes e visualize as estatísticas:

• No Dynamo, o Gerenciador de pacotes inclui pacotes de instalação, publicação e atualização.

1. Procurar pacotes on-line: Packages > Search for a Package...

2. Visualizar/editar pacotes instalados: Packages > Manage Packages...

3. Publicar um novo pacote: Packages > Publish New Package...

Publicar um pacote

Os pacotes são publicados do Gerenciador de pacotes no Dynamo. O processo recomendado é publicar localmente, testar o pacote e, em seguida, publicar on-line para compartilhar com a comunidade. Usando o estudo de caso NodeModel, vamos passar pelas etapas necessárias para publicar o nó RetangularGrid como um pacote localmente e, em seguida, on-line.

Inicie o Dynamo e selecione Packages > Publish New Package... para abrir a janela Publish a Package.

1. Selecionar Add file... para procurar arquivos para adicionar ao pacote

2. Selecionar os dois arquivos .dll no estudo de caso NodeModel

3. Selecionar Ok

Com os arquivos adicionados ao conteúdo do pacote, atribua um nome, uma descrição e uma versão ao pacote. A publicação de um pacote usando o Dynamo cria automaticamente um arquivo pkg.json.

Um pacote pronto para ser publicado.

1. Fornecer as informações necessárias para o nome, a descrição e a versão.

2. Publicar clicando em “Publicar localmente” e selecionar a pasta de pacotes do Dynamo: AppData\Roaming\Dynamo\Dynamo Core\1.3\packages para ter o nó disponível no Core. Sempre publique localmente até que o pacote esteja pronto para compartilhar.

Após a publicação de um pacote, os nós estarão disponíveis na biblioteca do Dynamo na categoria CustomNodeModel.

1. O pacote que acabamos de criar na biblioteca do Dynamo

Quando o pacote estiver pronto para publicação on-line, abra o Gerenciador de pacotes, escolha Publish e, em seguida, Publish Online.

1. Para ver como o Dynamo formatou o pacote, clicar nos três pontos verticais à direita de “CustomNodeModel” e escolher “Mostrar diretório raiz”

2. Selecionar Publish e, em seguida, Publish Online na janela “Publicar um pacote do Dynamo”.

3. Para excluir um pacote, selecionar Delete.

Como atualizar um pacote?

A atualização de um pacote é um processo semelhante ao da publicação. Abra o Gerenciador de pacotes e selecione Publish Version... no pacote que precisa ser atualizado e insira uma versão posterior.

1. Selecionar Publish Version para atualizar um pacote existente com novos arquivos no diretório raiz e, em seguida, escolher se ele deve ser publicado localmente ou on-line.

Cliente Web do Gerenciador de pacotes

O cliente Web do Gerenciador de pacotes permite que os usuários pesquisem e visualizem dados de pacotes, incluindo controle de versão, estatísticas de download e outras informações relevantes. Além disso, os autores do pacote podem fazer login para atualizar os detalhes do pacote, como informações de compatibilidade, diretamente por meio do cliente da Web.

Para obter mais informações sobre esses recursos, consulte a postagem do blog aqui: .

É possível acessar o cliente Web do Gerenciador de pacotes neste link: .

Atualizar os detalhes do pacote

Os autores podem editar a descrição do pacote, o link do site e o link do repositório seguindo estas etapas:

1. Em Meus pacotes, selecione o pacote e clique em Editar detalhes do pacote.

2. Adicione ou modifique os links do Site e do Repositório usando os respectivos campos.

3. Atualize a Descrição do pacote conforme necessário.

Observação: As atualizações podem levar até 15 minutos para serem atualizadas no Gerenciador de pacotes no Dynamo, já que as atualizações de servidor levam algum tempo. Há esforços em andamento para reduzir esse atraso.

Editar informações de compatibilidade para versões de pacote publicadas

É possível atualizar as informações de compatibilidade retroativamente para versões de pacotes publicadas anteriormente. Siga estas etapas:

Etapa 1:

1. Clique na versão do pacote que você deseja atualizar.

2. A lista Depende será preenchida automaticamente com os pacotes dos quais o pacote depende.

3. Clique no ícone de lápis ao lado de Compatibilidade para abrir o fluxo de trabalho Editar informações de compatibilidade.

Etapa 2:

Siga o fluxograma abaixo e consulte a tabela abaixo para entender qual opção funciona melhor para o pacote.

Vamos usar alguns exemplos para analisar alguns cenários:

Exemplo de pacote nº 1 – Conexão do Civil: esse pacote tem dependências de APIs com o Revit e o Civil 3D e não inclui uma coleção de nós principais (por exemplo: funções de geometria, funções matemáticas e/ou gerenciamento de lista). Então, neste caso, a opção ideal seria escolher a Opção 1. O pacote que corresponda ao intervalo de versões e/ou à lista de versões individuais será mostrado como compatível no Revit e no Civil 3D.

Exemplo de pacote nº 2 – Ritmo: esse pacote é uma coleção de nós específicos do Revit junto com uma coleção de nós principais. Nesse caso, o pacote tem dependências de hospedeiro. Mas também inclui nós principais que funcionarão no Dynamo Core. Então, nesse caso, a alternativa ideal seria a Opção 2. O pacote será mostrado como compatível no ambiente do Revit e do Dynamo Core (também chamado de Dynamo Sandbox) que corresponde ao intervalo de versões e/ou à lista de versões individuais.

Exemplo de pacote nº 3 – Kit de ferramentas de malha: esse pacote é um pacote do Dynamo Core que é uma coleção de nós de geometria que não tem dependências de hospedeiro. Então, nesse caso, a alternativa ideal seria a Opção 3. O pacote será mostrado como Compatível no Dynamo e em todos os ambientes de hospedeiro que correspondam ao intervalo de versões e/ou à lista de versões individuais.

Dependendo da opção selecionada, os campos específicos do Dynamo e/ou do hospedeiro serão exibidos conforme mostrado na imagem abaixo.

Se você estiver desenvolvendo montagens a serem publicadas como um pacote do Dynamo, o projeto poderá ser configurado para agrupar todos os recursos necessários e colocá-los em uma estrutura de diretório compatível com o pacote. Isso permitirá que o projeto seja rapidamente testado como um pacote e simulará a experiência do usuário.

Como compilar diretamente na pasta de pacotes

Há dois métodos para compilar um pacote no Visual Studio:

• Adicionar eventos pós-compilação através da caixa de diálogo Configurações do projeto que usam scripts xcopy ou Python para copiar os arquivos necessários

• Usar o destino de compilação “AfterBuild” no arquivo .csproj para criar tarefas de cópia de arquivos e diretórios

“AfterBuild” é o método preferido para esses tipos de operações (e o que é abordado neste guia), pois não depende da cópia de arquivos que podem não estar disponíveis no computador de compilação.

Copiar arquivos de pacote com o método AfterBuild

Configure a estrutura de diretórios no repositório para que os arquivos de origem sejam separados dos arquivos de pacote. Trabalhando com o estudo de caso CustomNodeModel, coloque o projeto do Visual Studio e todos os arquivos associados em uma nova pasta src. Todos os pacotes gerados pelo projeto serão armazenados nessa pasta. A estrutura de pastas deve ter este aspecto:

1. Mover os arquivos de projeto para a nova pasta src

Agora que os arquivos de origem estão em uma pasta separada, adicione um destino AfterBuild ao arquivo CustomNodeModel.csproj no Visual Studio. Isso deve copiar os arquivos necessários para uma nova pasta de pacote. Abra o arquivo CustomNodeModel.csproj em um editor de texto (usamos o ) e coloque o destino da compilação antes do identificador de fechamento </Project>. Esse destino AfterBuild copiará todos os arquivos .dll, .pbd, .xml e .config para uma nova pasta bin e criará as pastas dyf e extras.

Precisamos ter certeza de que o destino foi adicionado ao arquivo CustomNodeModel.csproj (não a outro arquivo de projeto) e que o projeto não tem nenhuma configuração Pós-compilação existente.

1. Colocar o destino AfterBuild antes do identificador </Project> final.

Na seção <ItemGroup>, são definidas um número de variáveis para representar tipos de arquivo específicos. Por exemplo, a variável Dll representa todos os arquivos no diretório de saída cuja extensão é .dll.

O objetivo da tarefa Copy é copiar todos os arquivos .dll para um diretório, especificamente a pasta de pacotes para a qual estamos compilando.

Os pacotes do Dynamo normalmente têm uma pasta dyf e extra para os nós personalizados do Dynamo e outros recursos, como imagens. Para criar essas pastas, é preciso usar uma tarefa MakeDir. Essa tarefa criará uma pasta se ela não existir. É possível adicionar arquivos manualmente a essa pasta.

Se você compilar o projeto, a pasta do projeto agora deverá ter uma pasta packages junto com a pasta src criada anteriormente. Dentro do diretório packages, há uma pasta que contém tudo o que é necessário para o pacote. Também precisamos copiar o arquivo pkg.json para a pasta do pacote para que o Dynamo saiba como carregar o pacote.

1. A nova pasta de pacotes que o destino AfterBuild criou

2. A pasta src existente com o projeto

3. As pastas dyf e extra criadas no destino AfterBuild

Agora você pode publicar o pacote usando o gerenciador de pacotes do Dynamo ou copiá-lo diretamente para o diretório de pacotes do Dynamo: <user>\AppData\Roaming\Dynamo\1.3\packages.

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

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

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...

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 .

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

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.

Algumas informações gerais sobre tipos de interoperabilidade

O que são tipos COM? –

A maneira padrão de usar tipos COM em C# é fazer referência e enviar as montagens de interoperabilidade principais (basicamente uma grande coleção de APIs) com o pacote.

Uma alternativa a isso é incorporar as PIA (montagens de interoperabilidade principais) na montagem gerenciada. Isso basicamente inclui apenas os tipos e membros que são realmente usados por uma montagem gerenciada. No entanto, essa abordagem apresenta alguns outros problemas, como a equivalência de tipos.

Esta publicação descreve muito bem o problema:

Extensões como pacotes

Visão geral

As extensões do Dynamo podem ser implantadas no gerenciador de pacotes, como as bibliotecas de nós normais do Dynamo. Quando um pacote instalado contém uma extensão de vista, a extensão é carregada no tempo de execução quando o Dynamo é carregado. É possível verificar o console do Dynamo para verificar se a extensão foi carregada corretamente.

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 .

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 .

• 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 .

• 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

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 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 . 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 ; 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:

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.

Considerações sobre o desempenho da interface do usuário do Dynamo

No momento em que este artigo foi escrito, o Dynamo usava principalmente o WPF (Windows Presentation Foundation) para renderizar sua interface do usuário. O WPF é um sistema baseado em xaml/binding complexo e poderoso. Como o Dynamo tem uma interface do usuário complexa, é fácil criar travamentos da interface do usuário, vazamentos de memória ou agrupar a execução do gráfico e as atualizações da interface do usuário de maneiras que degradam o desempenho.

Consulte a , que ajudará você a evitar algumas armadilhas comuns ao fazer alterações no código do Dynamo.

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

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”

O Dynamo é baseado no padrão de arquitetura do software

Usar métodos em GeometryPrimitiveConverter.cs

A classe GeometryPrimitiveConverter na biblioteca de códigos do DynamoRevit fornece vários métodos para converter entre tipos geométricos do Revit e do Dynamo. Esses métodos são úteis ao trabalhar com geometria em scripts do Dynamo que interagem com modelos do Revit.

Categorias de métodos

É possível agrupar os métodos em GeometryPrimitiveConverter.cs em quatro categorias principais:

1. Tipos do Proto para Revit: métodos que convertem tipos do Dynamo (Proto) em tipos do Revit.

2. Tipos do Revit para Proto: métodos que convertem tipos do Revit em tipos do Dynamo (Proto).

3. Graus e radianos: métodos que convertem entre graus e radianos.

4. X e UZ: métodos que lidam com a obtenção de vetores perpendiculares.

Tipos do Proto para Revit

ToRevitBoundingBox

Cria uma BoundingBoxXYZ do Revit com base em um sistema de coordenadas do Dynamo e em dois pontos de definição (mínimo e máximo).

public static Autodesk.Revit.DB.BoundingBoxXYZ ToRevitBoundingBox( Autodesk.DesignScript.Geometry.CoordinateSystem cs, Autodesk.DesignScript.Geometry.Point minPoint, Autodesk.DesignScript.Geometry.Point maxPoint, bool convertUnits = true)

ToRevitType (BoundingBox)

Converte uma BoundingBox do Dynamo em uma BoundingBoxXYZ do Revit.

O indicador convertUnits (true definido como padrão) determina se as coordenadas devem ser convertidas do sistema de unidades do Dynamo em unidades internas do Revit.

public static Autodesk.Revit.DB.BoundingBoxXYZ ToRevitType(this Autodesk.DesignScript.Geometry.BoundingBox bb, bool convertUnits = true)

ToRevitType (ponto)

Converte um ponto do Dynamo em um XYZ do Revit.

O indicador convertUnits (true definido como padrão) converte as coordenadas, se necessário.

public static Autodesk.Revit.DB.XYZ ToRevitType(this Autodesk.DesignScript.Geometry.Point pt, bool convertUnits = true)

ToRevitType (vetor)

Converte um vetor do Dynamo em um XYZ do Revit.

Observe que o indicador convertUnits tem como padrão false porque os vetores representam a direção e a magnitude, que normalmente não requerem conversão de unidade. A conversão pode afetar a direção e o comprimento do vetor.

public static Autodesk.Revit.DB.XYZ ToRevitType(this Vector vec, bool convertUnits = false)

ToXyz (ponto)

Converte um ponto do Dynamo em um XYZ do Revit.

public static Autodesk.Revit.DB.XYZ ToXyz(this Autodesk.DesignScript.Geometry.Point pt, bool convertUnits = true)

ToXyz (vetor)

Converte um vetor do Dynamo em um XYZ do Revit.

Observe que o indicador convertUnits tem como padrão false porque os vetores representam a direção e a magnitude, que normalmente não requerem conversão de unidade. A conversão pode afetar a direção e o comprimento do vetor.

public static Autodesk.Revit.DB.XYZ ToXyz(this Vector vec, bool convertUnits = false)

ToTransform

Converte um CoordinateSystem do Dynamo em uma transformação do Revit.

public static Autodesk.Revit.DB.Transform ToTransform(this CoordinateSystem cs, bool convertUnits = true)

ToPlane

Converte um plano do Dynamo em um plano do Revit.

public static Autodesk.Revit.DB.Plane ToPlane(this Autodesk.DesignScript.Geometry.Plane plane, bool convertUnits = true)

ToXyzs (pontos)

Converte coleções de objetos de ponto do Dynamo em coleções XYZ do Revit.

Retornar uma lista de XYZs. public static List<XYZ> ToXyzs(this List<Autodesk.DesignScript.Geometry.Point> list, bool convertUnits = true)

Retornar uma matriz de XYZs. public static XYZ[] ToXyzs(this Autodesk.DesignScript.Geometry.Point[] list, bool convertUnits = true)

ToXyzs (vetores)

Converte uma matriz de objetos de vetor do Dynamo em uma matriz de vetores XYZ do Revit.

public static XYZ[] ToXyzs(this Autodesk.DesignScript.Geometry.Vector[] list, bool convertUnits = false)

ToDoubleArray

Converte uma matriz de valores duplos em DoubleArray do Revit.

public static DoubleArray ToDoubleArray(this double[] list)

ToUvs

Converte uma matriz bidimensional (double[][]), em que cada matriz interna representa um par de valores (U e V) em uma matriz de objetos UV do Revit.

internal static Autodesk.Revit.DB.UV[] ToUvs(this double[][] uvArr)

ToDSUvs

Converte uma matriz bidimensional (double[][]), em que cada matriz interna representa um par de valores (U e V) em uma matriz de objetos UV do Dynamo.

internal static Autodesk.DesignScript.Geometry.UV[] ToDSUvs(this double[][] uvArr)

Exemplo de uso de tipos do Proto para Revit

Este exemplo mostra um método rápido e fácil de usar o método .ToXyz (ponto) para converter um Point.ByCoordinates do Dynamo em um XYZ do Revit.

Tipos do Revit para Proto

ToProtoType (BoundingBox)

Converte uma BoundingBoxXYZ do Revit em uma BoundingBox do Dynamo.

public static Autodesk.DesignScript.Geometry.BoundingBox ToProtoType(this Autodesk.Revit.DB.BoundingBoxXYZ xyz, bool convertUnits = true)

ToPoint (XYZ)

Converte um XYZ do Revit em um ponto do Dynamo.

public static Autodesk.DesignScript.Geometry.Point ToPoint(this XYZ xyz, bool convertUnits = true)

ToProtoType (ponto)

Converte um ponto do Revit em um ponto do Dynamo.

public static Autodesk.DesignScript.Geometry.Point ToProtoType(this Autodesk.Revit.DB.Point point, bool convertUnits = true)

ToVector (XYZ)

Converte um XYZ do Revit em um vetor do Dynamo.

public static Vector ToVector(this XYZ xyz, bool convertUnits = false)

ToProtoType (UV)

Converte um UV do Revit em um UV do Dynamo.

public static Autodesk.DesignScript.Geometry.UV ToProtoType(this Autodesk.Revit.DB.UV uv)

ToPlane (Plano do Revit)

Converte um plano do Revit em um plano do Dynamo.

public static Autodesk.DesignScript.Geometry.Plane ToPlane(this Autodesk.Revit.DB.Plane plane, bool convertUnits = true)

ToCoordinateSystem

Converte uma transformação do Revit em um CoordinateSystem do Dynamo.

public static CoordinateSystem ToCoordinateSystem(this Transform t, bool convertUnits = true)

ToPoints

Converte uma lista de pontos XYZ do Revit em uma lista de pontos do Dynamo.

public static List<Autodesk.DesignScript.Geometry.Point> ToPoints(this List<XYZ> list, bool convertUnits = true)

Exemplo de uso dos tipos do Revit para Proto

Este exemplo mostra um método rápido e fácil de usar o método .ToPoint (XYZ) para converter um XYZ do Revit em um ponto do Dynamo.

Graus e radianos

ToRadians

Converte graus em radianos.

public static double ToRadians(this double degrees) { return degrees * Math.PI / 180.0; }

ToDegrees

Converte radianos em graus.

public static double ToDegrees(this double degrees) { return degrees * 180.0 / Math.PI; }

Exemplo de uso de graus e radianos

Este exemplo mostra um método rápido e fácil de usar o método .ToRadianos para converter de graus em radianos.

X e UZ

GetPerpendicular (XYZ)

Esse método retorna um vetor XYZ perpendicular ao vetor XYZ fornecido.

public static XYZ GetPerpendicular(this XYZ xyz)

GetPerpendicular (vetor)

Esse método retorna um Vector do Dynamo perpendicular ao Vector do Dynamo fornecido.

public static Vector GetPerpendicular(this Vector vector)

Exemplo de uso de X e UZ

Este exemplo mostra um método rápido e fácil de usar o método .GetPerpendicular para obter o vetor perpendicular a um vetor de entrada.

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:

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

O arquivo ZeroTouchEssentials.cs

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.

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:

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

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:

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

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:

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

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

• 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:

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

• 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:

• 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:

O código-fonte pode ser clonado do Github:

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.

A obtenção de um layout desejado para o pacote depende dos tipos de nós que você incluirá no pacote. Os nós derivados do modelo de nó, os nós ZeroTouch e os nós personalizados têm um processo ligeiramente diferente para definir a categorização. É possível misturar e combinar esses tipos de nó dentro do mesmo pacote, mas isso exigirá uma combinação das estratégias descritas abaixo.

NodeModel

Por padrão, as bibliotecas NodeModel são organizadas com base na estrutura de classes.

O nó ficará localizado em Complementos em:

Também é possível substituir a categoria usando o atributo NodeCategory na classe ou no construtor, como mostrado abaixo.

O nó agora ficará localizado em Complementos em:

ZeroTouch

As bibliotecas ZeroTouch também são organizadas com base na estrutura de classes por padrão.

O nó ficará localizado em Complementos em:

Também é possível substituir a localização da estrutura da classe usando um arquivo XML de personalização do Dynamo.

• O arquivo XML deve ser nomeado adequadamente e ser incluído na pasta extra do pacote

  • PackageName_DynamoCustomization.xml

CustomNodes

Os nós personalizados são organizados com base no Category Name especificado durante a criação dos nós (usando a caixa de diálogo Novo nó personalizado).

AVISO O uso da notação de ponto em nomes de nós ou categorias resultará em subcategorias aninhadas adicionais. O . funcionará como um delimitador para determinar a hierarquia adicional. Esse é um novo comportamento na biblioteca para o Dynamo 2.0.

O nome da categoria pode ser atualizado posteriormente no arquivo .dyf (XML ou JSON)

Estratégias de migração de nós do pacote

Quando o autor de um pacote decide renomear um nó existente anterior em uma nova versão, ele deve fornecer um meio para migrar gráficos que contêm nós com os nomes antigos. Isso pode ser feito das seguintes maneiras:

Os nós ZeroTouch usam um arquivo Namespace.Migrations.XML localizado na pasta bin dos pacotes, como:

MyZeroTouchLib.MyNodes.SayHello para MyZeroTouchLib.MyNodes.SayHelloRENAMED

Os nós derivados do NodeModel usam o atributo AlsoKnownAs na classe, como:

SampleLibraryUI.Examples.DropDownExample para SampleLibraryUI.Examples.DropDownExampleRENAMED

Com um conhecimento básico do nó Sem toque já estabelecido, esta seção se aprofunda nas vantagens de personalizar os nós do Dynamo para aprimorar a funcionalidade e a experiência do usuário. Ao adicionar recursos como mensagens de aviso, mensagens informativas e ícones personalizados, é possível criar nós mais intuitivos, informativos e visualmente envolventes. Além de ajudar os usuários a entender possíveis problemas ou otimizar seus fluxos de trabalho, essas personalizações também fazem com que seus nós se destaquem como ferramentas profissionais e fáceis de usar.

Personalizar nós é uma excelente maneira de garantir que suas soluções sejam claras, confiáveis e adaptadas para atender às necessidades específicas do projeto.

Gerar mensagens de aviso personalizadas usando OnLogWarningMessage

No Dynamo, o método OnLogWarningMessage fornece uma maneira de registrar mensagens de aviso diretamente no console do Dynamo. Esse é um recurso poderoso, especialmente para os nós Sem toque, pois permite que os desenvolvedores alertem os usuários quando há problemas com entradas ou parâmetros que podem levar a um comportamento inesperado. Este guia ensinará como implementar OnLogWarningMessage em qualquer nó Sem Toque.

Etapas de implementação de OnLogWarningMessage

Etapa 1: Importar o namespace necessário

OnLogWarningMessage faz parte do namespace DynamoServices, por isso, comece adicionando-o ao arquivo do projeto.

Etapa 2: Identificar quando registrar avisos

Antes de adicionar uma mensagem de aviso, considere a lógica no método:

• Quais condições podem causar resultados incorretos ou inesperados?

• Há valores ou parâmetros de entrada específicos que o método requer para funcionar corretamente?

Exemplos de condições a serem verificadas:

• Valores fora do intervalo (por exemplo, if (inputValue < 0)).

• Coleções nulas ou vazias (por exemplo, if (list == null || list.Count == 0)).

• O tipo de dados não coincide (por exemplo, se um tipo de arquivo não for suportado).

Etapa 3: Usar o OnLogWarningMessage para registrar o aviso

Coloque chamadas OnLogWarningMessage onde são detectadas as condições que podem causar problemas. Quando a condição for atendida, registre uma mensagem de aviso que forneça orientação clara ao usuário.

Sintaxe para OnLogWarningMessage

Exemplo de implementações de OnLogWarningMessage

Para demonstrar OnLogWarningMessage na prática, aqui estão diferentes cenários que podem ser encontrados ao criar um nó Sem Toque.

Exemplo 1: Validar entradas numéricas

Neste exemplo, vamos nos basear no nó personalizado criado no “Estudo de caso do nó Sem toque – Nó de grade” anterior; um método denominado RectangularGrid que gera uma grade de retângulos com base em entradas xCount e yCount. Vamos percorrer o processo de teste Se uma entrada é inválida e, em seguida, usar OnLogWarningMessage para registrar um aviso e parar o processamento.

Usar OnLogWarningMessage para validação de entrada

Quando gerar uma grade com base em xCount e yCount. Recomenda-se garantir que os dois valores sejam inteiros positivos antes de continuar.

Neste exemplo:

• Condição: se xCount ou yCount for menor ou igual a zero.

• Mensagem: "Grid count values must be positive integers."

O aviso será mostrado no Dynamo se um usuário inserir valores zero ou negativos, ajudando-os a entender a entrada esperada.

Agora que sabemos como é, podemos implementá-lo no nó de exemplo Grades:

Exemplo 2: verificar coleções nulas ou vazias

Se o método exigir uma lista de pontos, mas um usuário passar uma lista vazia ou nula, será possível usar OnLogWarningMessage para informá-lo sobre o problema.

Neste exemplo:

• Condição: se a lista points for nula ou contiver menos de três pontos.

• Mensagem: "Point list cannot be null or have fewer than three points."

Avisa aos usuários que eles precisam passar por uma lista válida com pelo menos três pontos para formar um polígono.

Exemplo 3: verificar a compatibilidade de tipo de arquivo

Para um nó que processa caminhos de arquivo, pode ser necessário garantir que apenas determinados tipos de arquivo sejam permitidos. Se um tipo de arquivo sem suporte for detectado, registre um aviso.

Neste exemplo:

• Condição: se o caminho do arquivo não terminar com “.csv”.

• Mensagem: "Only CSV files are supported."

Avisa os usuários para garantir que estão transmitindo um arquivo CSV, ajudando a evitar problemas relacionados a formatos de arquivo incompatíveis.

Adicionar mensagens informativas com OnLogInfoMessage

No Dynamo, o OnLogInfoMessage do namespace DynamoServices permite que os desenvolvedores registrem mensagens informativas diretamente no console do Dynamo. Isso é útil para confirmar operações bem-sucedidas, comunicar o progresso ou fornecer informações adicionais sobre as ações do nó. Este guia ensinará como adicionar OnLogInfoMessage em qualquer nó Sem Toque para aprimorar o feedback e a experiência do usuário.

Etapas de implementação de OnLogInfoMessage

Etapa 1: Importar o namespace necessário

OnLogInfoMessage faz parte do namespace DynamoServices, por isso, comece adicionando-o ao arquivo do projeto.

Etapa 2: Identificar quando registrar as informações

Antes de adicionar uma mensagem de informação, pense no propósito do método:

• Quais informações seriam úteis para confirmar após a conclusão de uma ação?

• Existem etapas ou marcos importantes no método que os usuários talvez queiram conhecer?

Exemplos de confirmações úteis:

• Mensagens de conclusão (por exemplo, quando uma grade ou um modelo é totalmente criado).

• Detalhes dos dados processados (por exemplo, “10 itens processados com êxito”).

• Resumos de execução (por exemplo, parâmetros usados no processo).

Etapa3: Usar OnLogInfoMessage para registrar mensagens informativas

Coloque chamadas OnLogInfoMessage em pontos significativos em seu método. Quando ocorrer uma etapa ou conclusão importante, registre uma mensagem informativa para atualizar o usuário sobre o que aconteceu.

Sintaxe para OnLogInfoMessage

Exemplo de implementações de OnLogInfoMessage

Veja diferentes cenários para demonstrar usando OnLogInfoMessage nos nós Sem Toque.

Exemplo 1: Validar entradas numéricas

Neste exemplo, vamos nos basear no nó personalizado criado no “Estudo de caso do nó Sem toque – Nó de grade” anterior; um método denominado RectangularGrid que gera uma grade de retângulos com base em entradas xCount e yCount. Vamos percorrer o teste Se uma entrada é inválida e, em seguida, usar OnLogInfoMessage para fornecer informações após o nó ter concluído sua execução.

Usar OnLogInfoMessage para validação de entrada

Quando gerar uma grade com base em xCount e yCount. Depois de gerar a grade, recomenda-se confirmar sua criação registrando uma mensagem informativa com as dimensões da grade.

Neste exemplo:

• Condição: o processo de criação da grade foi concluído.

• Mensagem: "Successfully created a grid with dimensions {xCount}x{yCount}."

Essa mensagem informará aos usuários que a grade foi criada conforme especificado, ajudando-os a confirmar que o nó funcionou conforme o esperado.

Agora que sabemos como é, podemos implementá-lo no nó de exemplo Grades:

Exemplo 2: Fornecer informações de contagem de dados

Se estiver criando um nó que processa uma lista de pontos, talvez seja necessário registrar quantos pontos foram processados com êxito. Isso pode ser útil para grandes conjuntos de dados.

Neste exemplo:

• Condição: após a conclusão do loop, mostrando a contagem de itens processados.

• Mensagem: "6 points were processed successfully."

Essa mensagem ajudará os usuários a entender o resultado do processamento e confirmar que todos os pontos foram processados.

Exemplo 3: Resumir os parâmetros usados

Em alguns casos, é útil confirmar os parâmetros de entrada de um nó usado para concluir uma ação. Por exemplo, se o nó exportar dados para um arquivo, o registro do nome e do caminho do arquivo poderá tranquilizar os usuários de que o arquivo correto foi usado.

Neste exemplo:

• Condição: o processo de exportação é concluído com êxito.

• Mensagem: "Data exported successfully to {filePath}."

Essa mensagem confirma aos usuários que a exportação funcionou e mostra o caminho exato do arquivo, ajudando a evitar confusão sobre a localização dos arquivos.

Criar e adicionar documentação personalizada a nós

Documentação personalizada dos nós