{"id":18083,"date":"2026-08-28T14:21:19","date_gmt":"2026-08-28T17:21:19","guid":{"rendered":"https:\/\/kb.elipse.com.br\/?p=18083"},"modified":"2026-08-28T14:21:19","modified_gmt":"2026-08-28T17:21:19","slug":"links-da-raiz-dois-pontose-a-versao-do-viewer","status":"publish","type":"post","link":"https:\/\/kb.elipse.com.br\/en\/links-da-raiz-dois-pontose-a-versao-do-viewer\/","title":{"rendered":"Links da raiz (dois pontos) e a vers\u00e3o do Viewer."},"content":{"rendered":"
\n
\n

A partir do E3\/Power\/Water 6.9, um link iniciado por dois pontos (:<\/code>) \u00e9 resolvido da raiz do Dom\u00ednio. Como \u00e9 uma mudan\u00e7a de sintaxe, um Viewer de vers\u00e3o anterior n\u00e3o reconhece o :<\/code> e mostra o link como quebrado.<\/p>\n<\/div>\n<\/div>\n

\n
\n

1.<\/span> Introdu\u00e7\u00e3o<\/h2>\n

A partir do E3\/Power\/Water 6.9<\/strong> \u00e9 poss\u00edvel criar links da raiz<\/strong> \u2014 associa\u00e7\u00f5es cujo caminho come\u00e7a com dois pontos<\/strong> (:<\/code>), resolvidas direto da raiz do Dom\u00ednio em vez de relativas ao objeto que as cont\u00e9m. O recurso evita ambiguidade entre objetos de mesmo nome e melhora o desempenho. Como \u00e9 uma mudan\u00e7a de sintaxe, um Viewer de vers\u00e3o anterior<\/strong> (ex.: 6.8) n\u00e3o reconhece o :<\/code> e trata o link como inv\u00e1lido \u2014 \u00e9 o que ocorre ao conectar um Viewer antigo a um servidor j\u00e1 atualizado. Este artigo explica como os links s\u00e3o resolvidos com e sem os dois pontos, por que quebram no Viewer desatualizado e como resolver.<\/p>\n<\/section>\n

\n

2.<\/span> Como s\u00e3o os links da raiz (dois pontos)<\/h2>\n

Um link (associa\u00e7\u00e3o) normalmente aponta para outro objeto por um caminho relativo<\/strong> ao objeto que cont\u00e9m o link. Prefixar o caminho com dois pontos<\/strong> (:<\/code>) transforma-o em um link da raiz<\/strong>: o E3 passa a resolv\u00ea-lo a partir da raiz do Dom\u00ednio<\/strong>, ignorando o contexto do objeto de origem.<\/p>\n

Dados.Tanque1.Nivel<\/code>caminho relativo<\/strong> \u2014 resolvido a partir do objeto de origem.<\/span>
\n:Dados.Tanque1.Nivel<\/code>caminho da raiz<\/strong> \u2014 resolvido a partir da raiz do Dom\u00ednio.<\/span><\/div>\n<\/section>\n
\n

3.<\/span> Como o E3 resolve um link \u2014 com e sem os dois pontos<\/h2>\n

Sem os dois pontos (relativo \u2014 comportamento hist\u00f3rico).<\/strong> O E3 sobe<\/strong> na hierarquia a partir do objeto que cont\u00e9m o link e, no primeiro n\u00edvel cujo nome casa<\/strong> com o in\u00edcio do caminho, desce<\/strong> para resolver o restante. Se nenhum n\u00edvel casar, a busca chega \u00e0 raiz assim mesmo. O risco \u00e9 a ambiguidade: se existir, em um n\u00edvel acima, um objeto \u2014 ou at\u00e9 uma propriedade do pr\u00f3prio objeto de origem<\/strong> \u2014 com o mesmo nome do in\u00edcio do caminho, a resolu\u00e7\u00e3o “trava” no lugar errado e o link quebra.<\/p>\n

Com os dois pontos (for\u00e7ado da raiz).<\/strong> O comportamento depende do tipo de objeto:<\/p>\n

    \n
  • Objetos do servidor<\/strong> (Dados, Tags, pastas): o :<\/code> resolve direto da raiz<\/strong> do Dom\u00ednio, ignorando o contexto do objeto. Isso elimina os conflitos de nome e ainda acelera a resolu\u00e7\u00e3o \u2014 o ganho \u00e9 maior quanto mais fundo o objeto estiver na hierarquia.<\/li>\n
  • Objetos do Viewer<\/strong> (Telas, Quadros, o pr\u00f3prio Viewer): o :<\/code> faz o E3 primeiro tentar resolver no pr\u00f3prio Viewer<\/strong> e, se n\u00e3o for um link do Viewer, resolver no servidor sempre a partir da raiz<\/strong> \u2014 evitando a busca no contexto da Tela ou do Quadro.<\/li>\n<\/ul>\n<\/section>\n
    \n

    4.<\/span> Por que o link quebra em um Viewer desatualizado<\/h2>\n

    Os links da raiz s\u00e3o uma mudan\u00e7a de sintaxe sem compatibilidade retroativa<\/strong>. Tradicionalmente, os dois pontos separam o apelido de um Dom\u00ednio remoto<\/strong> do caminho do objeto (sintaxe Dom\u00ednio:Caminho<\/code>). Um :<\/code> no in\u00edcio<\/strong> do caminho, sem apelido antes, equivale a um nome de Dom\u00ednio vazio<\/strong> \u2014 o Dom\u00ednio local, mas resolvido da raiz. O interpretador de express\u00f5es das vers\u00f5es anteriores<\/strong> n\u00e3o aceita esse Dom\u00ednio vazio (espera sempre um Dom\u00ednio remoto ou um alias local) e trata o caminho como link inv\u00e1lido<\/strong>.<\/p>\n

    \n

    Viewer antigo + servidor novo<\/p>\n

    Uma aplica\u00e7\u00e3o que usa os dois pontos exige o Viewer atualizado<\/strong>. Um Viewer 6.8 conectado a um servidor 6.9 exibe os links com :<\/code> como quebrados em runtime, embora o mesmo projeto funcione normalmente com o Viewer na vers\u00e3o do servidor.<\/p>\n<\/div>\n<\/section>\n

    \n

    5.<\/span> Solu\u00e7\u00e3o: atualize o Viewer para a vers\u00e3o do servidor<\/h2>\n

    Mantenha o Viewer na mesma vers\u00e3o do servidor<\/strong> (6.9 ou superior). Depois de atualizado, os links da raiz passam a ser reconhecidos e resolvidos corretamente. Padronize a vers\u00e3o de todas as esta\u00e7\u00f5es<\/strong> (servidor e Viewers) antes de publicar links da raiz na aplica\u00e7\u00e3o.<\/p>\n<\/section>\n

    \n

    6.<\/span> Benef\u00edcios de manter os dois pontos<\/h2>\n

    Com a vers\u00e3o padronizada, vale manter os links da raiz:<\/p>\n

      \n
    • Fim da ambiguidade<\/strong> entre objetos (ou propriedades) de mesmo nome em n\u00edveis diferentes.<\/li>\n
    • Desempenho.<\/strong> A resolu\u00e7\u00e3o direta da raiz \u00e9 mais r\u00e1pida, sobretudo em hierarquias profundas e do lado servidor. Em testes internos, for\u00e7ar os links da raiz reduziu em cerca de 10%<\/strong> o tempo de inicializa\u00e7\u00e3o de uma aplica\u00e7\u00e3o com 100 mil links entre objetos do servidor; em outra medi\u00e7\u00e3o, o tempo de ativa\u00e7\u00e3o de um Data Server com 10 mil tags internos em uma \u00e1rvore de quatro n\u00edveis de pastas caiu cerca de 15%<\/strong>.<\/li>\n<\/ul>\n<\/section>\n
      \n

      7.<\/span> Observa\u00e7\u00f5es e boas pr\u00e1ticas<\/h2>\n
        \n
      • O AppBrowser ajuda a montar a Fonte.<\/strong> Ao criar associa\u00e7\u00f5es pelo AppBrowser, o caminho normalmente j\u00e1 \u00e9 gerado como link da raiz (com o :<\/code>).<\/li>\n
      • No E3 Studio, uma Fonte v\u00e1lida aparece em azul<\/strong>; um caminho inv\u00e1lido \u00e9 sinalizado como erro \u2014 \u00fatil para identificar um link quebrado j\u00e1 na configura\u00e7\u00e3o.<\/li>\n
      • Ao digitar a Fonte manualmente<\/strong>, comece o caminho com :<\/code> para for\u00e7ar a resolu\u00e7\u00e3o da raiz. Por script, informe o caminho j\u00e1 com os dois pontos ao criar a associa\u00e7\u00e3o:<\/li>\n<\/ul>\n
        \n
        ' Associa\u00e7\u00e3o simples resolvida a partir da raiz do Dom\u00ednio<\/span>\r\nObjeto.Links.CreateLink \"Value\"<\/span>, \":Dados.Tanque1.Nivel\"<\/span>, 0<\/pre>\n<\/div>\n
          \n
        • Contexto.<\/strong> Antes do recurso, os links de DBServer em F\u00f3rmula, Hist\u00f3rico e Storage j\u00e1 eram resolvidos da raiz para evitar conflito com uma propriedade de mesmo nome do pr\u00f3prio objeto. Os dois pontos generalizam esse comportamento para qualquer associa\u00e7\u00e3o.<\/li>\n<\/ul>\n<\/section>\n
          <\/section>\n