PTInternal e StaticCall serão bloqueadas – O que muda nas customizações?

Recentemente recebi a informação de que as funções PTInternal e StaticCall serão bloqueadas para uso dos desenvolvedores. Se você utiliza essas funções nos seus fontes, é recomendado começar a substituição o quanto antes. Os trechos já existentes também precisarão ser reescritos. O motivo do bloqueio não foi informado.

A previsão é que essa mudança ocorra na versão 33 do sistema, com o binário HARPIA.

Eu utilizo ambas funções com frequência nos desenvolvimentos.

Quando utilizei o PTInternal:

• Rotinas multithread para controle de mensagens no monitor.
• Rotinas com threads em paralelo (vários appservers).
• Rotinas single-thread demoradas.
• Possivelmente surgirá uma nova função substituta (até 2021-10-05 não existia).
  • Nova função criada: FWMonitorMsg
  • Disponível a partir da release 33 ou lib 20211116 em releases inferiores.

Quando utilizei o StaticCall:

Observações importantes

• ADVPL possui limitação de 10 caracteres para funções e variáveis.
• Prefixo U_ consome 2 caracteres.
• User Functions são globais, não podem existir nomes iguais nos primeiros 8 caracteres.
• TLPP é relativamente recente.
• TLPP não aceita MVC.

Funções de menu (aRotina), MVC ou não

• Centralizar funções estáticas dentro do próprio fonte ao invés de usar U_ global.
• Evita conflitos de nomes repetidos em fontes diferentes.
• Exemplo:

  aAdd( aSinc, { "Marca", "StaticCall(ANYMKA01,ArmSend)", 0, 3, 0, NIL } )

  • 8 caracteres apenas.
  • Em User Function ficaria: U_ArmSend (10 caracteres).
  • Maior risco de conflito de nome.
• Por que não chamar direto?

  aAdd( aRotina, { "Armazéns a Enviar", "ArmSend()", 0, 3, 0, NIL } )

  • A função não é encontrada (erro conhecido desde P10).
• Impacta também grids (MSNewGetDados)
  • cFieldOK / cLinhaOK / cTudoOK
  • Necessário usar U_ e criatividade nos nomes.
  • Cuidado para não repetir nomes nos 8 primeiros caracteres.

Validações no SX3 / SX*

• Se você executa static direto para evitar conflito de nome:
  • Reescrever usando U_ ou TLPP.

Variáveis static com controle de erro

• Trechos que retornam variáveis static precisarão ser reescritos.
• Exemplo:
  • GetError → 8 caracteres.
  • U_GetError → 10 caracteres.
  • Não pode existir outro GetError em outro fonte.
  • Opções: GetErro1, GetErro2, TLPP, ou classes.

Outra alternativa: manter apenas uma User Function com parâmetros

• Parâmetros como cExec / nType / cParam.
• Mas atenção: se a função roda em schedule/onstart, empresa e filial são enviadas (cEmp, cFil).

Geração de DanfeII por StaticCall

• Não irá funcionar.
• Muitos clientes geram DanfeII por customização usando StaticCall.
• Também há casos de envio de PDF por e-mail ou integração.
• Esses trechos precisarão ser reescritos.

• Manter uma User Function global e o restante Static, executado via MenuDef.
• Entre outras situações similares…

FIM

Gostou? Compartilhe com seus amigos e deixe um comentário! 😎

Um abraço, até a próxima!