Recentemente, vários clientes reclamaram de erros no C3DRENESG4, com algo assim:
Ou ainda, ao numerar:
Este erro também afeta o C3DMEMO:
Este erro ocorre por que o seu Windows foi atualizado, ou teve alguma configuração nas opções de internet que invalidaram a forma como o Java Script identifica as variáveis. Sim, meus plugins também usavam isso. Mais precisamente neste código:
viewport = document.getElementById("viewport");Antes, meu código não tinha essa atribuição, pois “viewport” já era o “id” da área onde era desenhado o preview. Enfim, adicionando a linha acima, OK. Ou quase… Outros erros ocorreram com os eventos do Java Script, por conta dessa atualização ou configuração.
A fim, de resolver este problema, abandonei o código que usava o Java Script, em favor do WPF.
Esta atualização ocorreu no executável “TBN2NET.exe”. Por isso todos os plugins são afetados. Se você reparou um executável com este nome na pasta dos meus plugins, ao chamar o comando “Sobre” (na linha de comando digite: TBN2C3DABOUT, TBN2CADABOUT, C3DMEMOABOUT, DDMABOUT, C3DRENESGABOUT ou SABOUT) dos plugins, verá algo assim:
Observe que ele mostra o local onde o plugin está e também o tbn2net.exe (ou dll). Neste caso, veja que eles não estão na mesma pasta.
Quando um plugin TBN2NET indica que há uma atualização, é recomendado atualizar TODOS os que você tem ao mesmo tempo
Muito bem. O próximo problema encontrado, foi quanto a instalação dos plugins na pasta:
C:\ProgramData\Autodesk\ApplicationPlugins
O Civil 3D 2026 (e o AutoCAD), não carrega mais automaticamente desta pasta. Só carrega manualmente, com o NETLOAD.
O motivo parece ter a ver com políticas de segurança. Em grandes empresas, os usuários normalmente não tem permissão para instalar programas ou plugins, tendo de recorrer ao TI da empresa para fazê-lo. E isso costuma ser um saco… “Já abriu o chamado?”, abre, espera…. Enfim. Esta pasta em geral fica bloqueada para o usuário normal.
Aí o TI instala nesta pasta, mas a deixa bloqueada para escrita e o plugin falha ao carregar o MENU.
Então mudei a pasta de instalação dos plugins para a pasta:
C:\Users\<seu nome de usuário>\AppData\Roaming\Autodesk\ApplicationPlugins
Esta pasta “deveria” ser a caixinha de areia do usuário, algo como a pasta “meus documentos” onde ele pode salvar coisas…. Sejam elas arquivos do WORD ou DLLs….
MASSSS, esses TIs as vezes BLOQUEIAM esta pasta também. Por que? bem, segurança.
Os instaladores dos plugins não exigiam privilégios de administrador para instalar.
Para a Autodesk, isto é ruim, inclusive, se quiser publicar o plugin na loja oficial deles, o instalador DEVE requisitar privilégios de administrador.
Fiz isso e me arrependi amargamente… Em um dia, VÁRIOS clientes reclamaram dessa exigência e sabe por que? Por causa do ticket de suporte!!!!!!
Da abertura do ticket até a conclusão, pode demorar DIAS….
Então, vamos lá, removemos essa necessidade de privilégios do administrador para INSTALAR. Mas ainda esbarramos no fato da pasta padrão estar bloqueada.
Aí a solução é instalar num pendrive. Incrível, mas o TI não pensa nessa opção e raramente usar pendrive é bloqueado… (não conte para o TI da sua empresa)
Algumas empresas fazem testes para homologar o seu plugin e um deles, é verificar se está assinado digitalmente. Se você faz isso, sabe que não é exatamente barato ter uma chave de assinatura de software. Então seria bem interessante que o seu TI aprendesse a adicionar excessões na política de segurança, para permitir a instalação de programas assinados, desde que essa assinatura já tenha sido validada pela empresa.
Isso permitiria ao próprio usuário fazer a atualização, sem ter de abrir um ticket de suporte, mas parece que os TI se importam muito com o número de tickets abertos, enfim.
Então se você é o TI da sua empresa, me desculpe a rudez!
Agora, vem a Autodesk. Vamos lá, eu até posso fazer um instalador que pede permissão de administrador, só pra satisfazer esta política da Autodesk e poder publicar na sua loja. O problema que o processo é bem demorado. Levou uns 2 meses para eu conseguir publicar o primeiro e os demais também demoraram. o SOLIDOS já está a uns 2 ANOS lá, parado na área de “rascunho” e não publica…. Por que será????
Até tentei falar com o suporte da loja, que fica na ÍNDIA. Já falou com um indiano em INGLÊS? Pois é… Não dá, pelo menos para mim….
Mas continuando, Você superou o TI, superou as pastas bloqueadas e deu tudo certo…. Só que não.
A Autodesk inventa a variável de sistema SECURELOAD.
Se ela estiver em 1, aparece aquela tela do security concern:
Esta tela é do AutoCAD 2014. Para as versões mais novas, é assim:
Se você colocar em SECURELOAD em 2, o NETLOAD não funciona. E credite, tem TI que coloca em 2. não sei se é por “graça” ou por segurança.
Segurança não pode ser, pois o usuário pode mudar seu valor sem permissão de administrador.
Se colocar SECURELOAD em 0, a tela não aparece. Aliás Autodesk, por que diabos essa variável??? O usuário CHAMOU O NETLOAD, ELE QUER CARREGAR A DLL!!!
E você TI, por que? Por que colocar SECURELOAD em 2???
Mas calma, ainda não falamos do usuário.
A Autodesk desabilitou o autoload na pasta “C:\ProgramData\Autodesk\ApplicationPlugins”. O usuário (ou o TI) vai lá de má vontade atualizar o plugin e ele agora vai para “C:\Users\<nome de usuário>\AppData\Roaming\Autodesk\ApplicationPlugins”. Mas ele não DESINSTALOU antes de atualizar.
Agora tem 2 versões do plugin no computador. Se abre o Civil 3D 2026, ok, carrega na pasta do usuário. Mas se abre o Civil 3D 2025 ou inferior…. Ai PARECE dar preferência para ProgramData. Aí os problemas começaram, pois OBVIAMENTE ele tem mais de uma versão do Civil 3D na máquina, seja por política de atualização da empresa, seja por que são “genéricos”…
Semana passada tive uma discussão com um gestor de uma empresa, reclamando do número excecivo de atualizações do SOLIDOS.
Expliquei, que ocorreram por conta de atualizações no Windows e no Civil 3D, que ocorreram muito próximas. E certas coisas nao tem como prever como vai se comportar.
Um exemplo:
Este erro estava ocorrendo em duas situações:
- Ao clicar o grip point de um alinhamento ( o que isso teria a ver com o SOLIDOS )
- Ao abrir um desenho em que foi feito COPY/PASTE de dispositivos do SOLIDOS
O primeiro bug ocorria por que, AO CLICAR um grip point do alinhamento, internamente o Civil 3D cria um bloco e o apaga imediatamente. Só que isso dispara eventos de “ObjectModified” no database. Esse evento é monitorado pelo SOLIDOS, para que ele processe as modificações. Durante o processamento, ele tenta acessar certas partes do banco de dados que APARENTEMENTE estão sendo MODIFICADAS pelo “clicar do grip point” em uma transação AINDA EM CURSO.
Se você não entendeu nada: Sabe quando abre a barra de edição de geometria do Ailinhamento e todos os botões estão desabilitados e só reiniciando resolve? Pois é. Uma transação aberta no banco de dados que não FOI FECHADA.
O caso que, com a transação do grip point aberta, o SOLIDOS abre mais uma transação com o banco de dados e tenta abrir um objeto, que já esta aberto na outra transação.
Eu podia prever isso? Ah sim, com muitos testes, sim. O Erro não ocorria no Civil 3D 2020, mas tornava o 2023/2025 quase impossível de trabalhar… Esse erro é só usuário que consegue… Sabe o dedo podre? hehehehe
Já o segundo erro, ocorria porque alguma coisa do desenho em que foi feito COPY/PASTE estava com o layer travado. Aí o SOLIDOS tentava recuperar informações de algo bloqueado e dava erro.
Bom, os erros obviamente foram corrigidos. E adivinha, tem atualização no SOLIDOS novamente, Pro TI receber mais um ticket, heheheh
Calma, logo termina.
Para completar, o Civil 3D agora permite conectar uma PIPENETWORK em outra. Isso mesmo. Nos testes que fiz, 2024, 2025 e 2026 permitem esta barbaridade.
Quais as implicações disso? Vamos lá: a “rede A” está no extremo norte do projeto e a “rede B” está no extremo sul. Elas não tem ligação física.
MASSSSSSS, [ênfase no mas] o usuário consegue chamar a edição da “rede A”, desenhar novos tubos próximos à “rede B” e conectar o tubo da “rede A” nas estruturas da “rede B”.
É. imagine a confusão que isso vai causar. E pra piorar, o tubo da “rede A” irá constar na “rede B” e ao chamar o comando C3DCALC do C3DRENESG4, aparece isto:
O erro ocorre quando o comando tenta obter dados das estruturas conectadas ao tubo. Como o tubo e as estrutura não estão na mesma rede, ele se perde e mostra este erro. Adicionei uma verificação e agora o plugin informa:
Você sempre quiz conectar duas redes, eu sei. NÃO É BOA IDEIA!
Tá pra finalizar: Pipes Catalog
Mano, o que tem de bug no PIpes Catalog não está escrito….
La em 2013, o C3DRENESG2 ( sim, versão 2) implementava algumas Pipe Rules. Abandonei, pois só funcionava se as DLLs estivessem numa pasta específica e adivinha, escondida e somente leitura.
Aí Adicionar novos dispositivos usando o PartBuilder, não é para qualquer um. Dá uma olhada:
Compare com o SOLIDOS:
Como criar uma boca de bueiro no SOLIDOS
Aí, tente adicionar propriedades ao dispositivo do PartBuilder, editando os XML. Vai lá, é BEM SIMPLES, vai dizer o concorrente.
Aí, lembra que a pasta de instalação mudou? Pois é. o Catálogo MUDOU DE LUGAR. O PipeNetwork não funciona mais…. A solução? Usar o comando SETNETWORKCATALOG.
Usuários do C3DRENESG4 já são “macacos velhos” nisso, mas a maioria nem se lembra disso…. Aí vem dizer que o C3DRENESG4 não está funcionando, na sexta-feira, depois das 18h. Vai me desculpar, mas suporte IMEDIATO somente em horário comercial.
Mas calma, este é o último:
Um erro relacionado ao Civil 3D e edição de lista de material: https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/Error-Script-Control-msscript-ocx-when-creating-pipe-network.html?st=Msscript.ocx
O que o internet explorer tem com isso? nem imagino, mas reinstalar (instalação limpa, REMOVE tudo antes de instalar) o Civil 3D, PARECE funcionar…