Esses dias eu fiz um aplicativo para .NET inicialmente para AutoCAD 2012 que tinha uma simples formulário que chamava os comandos pelos botões, até ai perfeito e eficiente. Quando a empresa atualizou para AutoCAD 2013 fiz atualização da API já que era completamente incompatível e para minha surpresa compilou perfeitamente! Só que não... os comandos não funcionavam mais...
É muito comum querer chamar comandos de um ou outro dos ambientes de programação do AutoCAD. Embora seja mais limpa (da perspectiva de um purista) para usar uma API para executar a tarefa que você quiser, a maneira mais rápida - e aquela que vai apelar para os pragmáticos entre nós é muitas vezes para chamar uma seqüência de comandos.
Vamos pegar o exemplo simples de adicionar uma linha. Aqui está o que você faria a partir dos diferentes ambientes de uma perspectiva de API de baixo nível:
- LISP - criar uma lista de associação que representa a entidade e, em seguida, (entmake) que
- VBA (ou COM) - obter o objeto modelspace do desenho ativo e chamar AddLine (a API COM é provavelmente o mais simples a esse respeito)
- NET e ObjectARX - abrir a tabela de bloco e, em seguida, o modelo de espaço de registro da tabela de bloco, crie um novo objeto de linha e anexá-lo para o espaço do modelo (e para a transação, se você estiver usando-os), fechando os vários objetos ao longo do caminho
Depois comecei a programar para AutoCAD com LISP a maneira mais simples de fazer o que você quer é chamar uma linha de comando, passando os pontos inicial e final é dessa forma:
(command "_LINE" "0,0,0" "100,100,0" "")
LISP é ótima nesse aspecto: como você não é capaz de definir comandos nativos (apenas LISP), é perfeitamente aceitável para usá-lo para comandos de script para fazer o que quiser, em vez de confiar em APIs de baixo nível.
ObjectARX tem grandes problemas para chamar comandos nativos por isso a necessidade de estratégias para fazer isso. A verdade é que o melhor para chamar comandos é usando acadCommand() do ObjectARX, ou criando um comando de "chamamamento" registrado como uma função LISP usando acadDefun().
Mas se você quer chamar ainda existem algumas opções alternativas no ObjectARX:
- ads_queueexpr()
- Se destina a ser usado a partir de acrxEntryPoint() para executar uma seqüência de comandos depois de (s::startup) foi chamado de LISP (como você não são capazes de usar acedCommand() a partir deste contexto), volta para ir ao mesmo lugar
- Você precisa declará-la a si mesmo (Extern "C" ads_queueexpr void (Acar *);) antes do uso
- Foi sem suporte, desde que me lembro, mas é amplamente utilizado e mencionado na seção Tips & Techniques no ObjectARX Developer's Guide
- AcApDocManager::sendStringToExecute()
- Esta função tem a vantagem de ter uma série de argumentos de execução que facilitam tanto auditar a utilização da função como esconder a utilização dela, como você envia um string para ser executado você monta o comando como se fosse um script.
- ::SendMessage()
- Esta é uma plataforma API Win32 e assim pode ser utilizado para chamar comandos de AutoCAD de um cliente externo - se você quer lançar toda sua aplicação do AutoCAD isso é possível.
- IAcadDocument::SendCommand()
- Este método COM é a única maneira (que não acedCommand() ou acedCmd()) para executar um comando de forma síncrona de AutoCAD.
- acedCommand ()
Este é o ObjectARX equivalente, e é genuinamente síncrona. Infelizmente há problemas com a usá-lo partir diretamente um nativo-registrado.
Esse artigo eu fiz baseado no artigo do Kean Walmsley.
Comentários
Postar um comentário