Mapear propriedades das classes do CT-e com RTTI

[Gabriel Bonzanini]

Bom dia pessoal.

 

Primeiramente, gostaria de elogiar o refactoring efetuado há alguns meses atrás, deixando o código-fonte dos documentos eletrônicos mais limpo, organizado e estruturado.

 

Apesar de todas as melhorias, acabei tendo uma pequena perda a partir dele: em nossa tela de emissão de Carta de Correção Eletrônica p/ CT-e, eu havia implementado uma forma dinâmica de obter todas as propriedades que podem ser corrigidas em um CT-e através da seguinte fução RTTI:

 

var
  PropList: PPropList;
begin
  GetPropList(pcteCTe.TCTe.ClassInfo, PropList);

...

Essa função retornava todas as propriedades da classe e de todas as classes internas, restando apenas o trabalho de remover da lista as tags para as quais não é permitida a alteração (conforme pág. 225 do manual de integração 3.00):

 

O que ocorre é que a maioria das propriedades dos componentes, inclusive desta classe, foram passadas de published para public, tornando-as invisíveis externamente via RTTI.

 

O que vocês acham que eu poderia fazer neste caso? Gostaria de saber também se há muitas vantagens em tornar as propriedades public, motivando assim esta mudança no refactoring.

 

Desde já agradeço a atenção. Abraço,

Gabriel Bonzanini.

[Gabriel Bonzanini]

Aceito métodos alternativos... Como os colegas fazem para listar as tags para as quais a correção é permitida?

[everson.turossi]

Aqui faço da seguinte forma, deixo livre para digitação todos os campos e valido na gravação se a tag e grupo digitados permitem correção. Quanto as tags que podem ser corrigidas, ai eu tenho um menu de acesso rápido onde o usuário seleciona uma das opções a ser corrigidas e então é completado o grupo e a tag. Não vi a necessidade de criar uma rotina com todas as tags existentes pois as correções a serem feitas na maioria dos casos ficam limitadas a 4 ou 5 tags como por exemplo a CFOP.

[Gabriel Bonzanini]

1 hora atrás, everson.turossi disse:

Aqui faço da seguinte forma, deixo livre para digitação todos os campos e valido na gravação se a tag e grupo digitados permitem correção. Quanto as tags que podem ser corrigidas, ai eu tenho um menu de acesso rápido onde o usuário seleciona uma das opções a ser corrigidas e então é completado o grupo e a tag. Não vi a necessidade de criar uma rotina com todas as tags existentes pois as correções a serem feitas na maioria dos casos ficam limitadas a 4 ou 5 tags como por exemplo a CFOP.

Olá @everson.turossi! Obrigado pelo retorno.

 

Tem razão, geralmente a correção gira em torno de algumas poucas tags. Porém, sempre tem aquele cliente que deseja alterar/corrigir uma informação relacionada à valores, documentos vinculados, etc., e restringir a utilização destas informações significa uma ligação de suporte a menos... Sem contar que fica mais transparente ao usuário, que seguidamente apresenta aquela dúvida "Posso corrigir isto?" (se estiver na lista, pode). Em últimos casos, vou ter que fazer o caminho inverso, listando tudo o que pode ser corrigido "hard coded", com a desvantagem de ter que lembrar de ajustar quando tags forem inclusas/modificadas no layout.

Editado 8 Julho, 2019 por Gabriel Bonzanini

[Gabriel Bonzanini]

Estamos criando uma lista fixa dos campos que podem ser alterados.

Apenas para encerrar o tópico, e por curiosidade: algum dos programadores poderia comentar acerca das vantagens que motivaram a alteração da seção das propriedades (de published para public), removendo assim o RTTI das mesmas?

 

Grato pela atenção.

[Gabriel Bonzanini]

Em 19/07/2019 at 12:00, Gabriel Bonzanini disse:

Estamos criando uma lista fixa dos campos que podem ser alterados.

Apenas para encerrar o tópico, e por curiosidade: algum dos programadores poderia comentar acerca das vantagens que motivaram a alteração da seção das propriedades (de published para public), removendo assim o RTTI das mesmas?

 

Grato pela atenção.

Olá pessoal.

 

Perdão pelos posts em sequência, mas é que já faz algum tempo e gostaria de encerrar este assunto... Alguém que tenha participado do refactoring poderia dar um retorno a respeito da alteração em si?

 

Grato pela atenção.

[Rafael Dias]

Teoricamente a unica vantagem é diminuir o tamanho do exe pois não vai ter as informações de rtti de resto é basicamente a mesma coisa, se não estou enganado nos Delphi mais atual não faz diferença ser ou não published.
 

[Daniel Simoes]

Veja esse tópico

 

[Gabriel Bonzanini]

Muito obrigado pelo retorno! Vou estudar e implementar o método alternativo mencionado neste outro tópico.

Abraço e sucesso a todos.

[Italo Giurizzato Junior]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.