ADVPL - StaticCall e PTInternal bloqueadas

Recentemente, recebi a informação que as funções PTInternal e StaticCall serão bloqueadas para uso dos desenvolvedores. Se você, caro leitor, utiliza elas, melhor ir alterando nos próximos fontes. Os fontes já criados, será necessário reescrever os trechos. O motivo do bloqueio, não sei.

A previsão é para versão 33 do sistema, binário HARPIA.

Eu utilizo ambas funções nos desenvolvimentos.

Quando utilizei o PTInternal:

• Rotinas multihread para controle de mensagens no monitor.
• Rotinas com thread em paralelo (vários appservers) + threads.
• Em algumas rotinas single thread demorada.
• Pode ser que seja criado alguma outra função para o caso, não existe até o momento (2021.10.05).
  • Função nova criada: https://tdn.totvs.com/display/framework/FWMonitorMsg
  • Esta função está disponível a partir da release 33 do Protheus. Em releases abaixo da 33 está disponível a partir do pacote de lib 20211116

Quando utilizei o StaticCall:

• OBS:
  • O ADVPL possui limitação de 10 caracteres para funções e variáveis.
  • O U_ consome 2 caracter.
  • User Funcion é global, não pode existir nomes iguais dentro dos 8 caracteres.
  • TLPP é "recente".
  • TLPP não aceita MVC.
• Função de menu (aRotina), MVC ou não.
  • Centralizar as funções statics dentro do fonte ao invés de global com U_.
  • Evitar de nome duplicado em fontes separado. Quanto mais desenvolver e criar funções U_, maior chance de criar um nome já existente.
  • Exemplo:
    • aAdd( aSinc, { 'Marca'             , 'StaticCall(ANYMKA01,ArmSend)', 0, 3, 0, NIL } )
      
      • Aqui são 8 caracter.
      • Na user funcion, ficaria U_ArmSend, 10 caracter.
      • Chance de conflitar com outro fonte, além de ficar global.
    • Mas porque não chamar direto? aAdd( aRotina, { 'Armazéns a Enviar' , "ArmSend()", 0, 3, 0, NIL } )
      • Ocorre o erro abaixo, não encontra a função.
    • Isso ocorre desde P10 que me lembro, não encontrei outra solução a não ser U_ ou classes.
• Esse exemplo de menu se estende para grids (MSNewGetDados).
  • cFieldOK / cLinhaOK / cTudoOK
  • Necessário usar U_ e ser criativo com os nomes.
  • Atenção para não declarar nomes iguais (8 primeiros caracteres).
  • Se seu fonte se chama: UDCOMA01, poderia chamar seu fieldOK de UDCOMA01_FIELDOK.
    • Ops, pode não, estourando 10 caracter no ADVPL (Chance de conflitar).
    • Solução seria o TLPP.
    • TLPP não funciona o MVC, nada disso no MENUDEF.

• Campos de validação no SX3/SX**** executando static direto para não conflitar nome?
  • Reescrever com U_ ou TLPP como mencionado.
• Fontes com variável static com controle de erro (ou outro controle) onde é retornado a mesma?
  • Reescrever como mencionado.
  • Exemplo:
    • GetError (8 caracter).
    • U_GetError (10 caracter).
    • Não poderá ter outro GetError em outro fonte.
      • É so mudar para GetErro1, GetErro2.
      • TLPP, NomeDoFonte_GetErro?
    • Resolve com classe, só reescrever, easy easy. 🤘
• Outra alternativa, será criar parâmetro na User Function (Manter somente uma no fonte).
  • cExec / nType / cParam
    • Controlar a execução da static e return (xRet / Indefinido). 
  • A atenção nesse caso se a mesma é executada no schedule / onstart, onde é enviado o parâmetro de empresa e filial.
    • aJob || cEmp e cFil. 
      • Depende de onde é chamado.
• Gera as danfeII por staticCall?
  • Não vai funcionar.
  • Já vi muitos casos que é gerado a danfeII por customização executando o fonte padrão com staticCall. 
  • Outros casos, é gerado o PDF e enviado por e-mail ou para integração.
  • Será necessário reescrever os trechos necessários.
• Manter uma User Function (GLOBAL) e o restante Static, podendo ser executado via MenuDef.
• Etc............

FIM

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

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