Pesquisar na Comunidade
Showing results for tags 'classes'.
Encontrado 2 registros
-
ATENÇÃO: ACBr está adotando as classes baseadas em ACBrXMLDocument como padrão!
um tópico no fórum postou Diego Foliene Notícias do ACBr
Olá pessoal! Se você não sabe do que se trata as classes baseadas em ACBrXMLDocument, o tópico abaixo tem mais detalhes: Mas em um resumo: São classes criadas de forma a utilizar as vantagens da LibXML para leitura e escrita dos arquivos XML. Elas são mais rápidas do que as classes baseadas na PCN. Elas foram criadas com o objetivo de substituir a PCN. Como podem ver no tópico indicado acima, desde antes de dezembro de 2024 essas novas classes já estão disponíveis e podem ser utilizadas pela comunidade através de opção no instalador. Agora, 6 meses depois, decidimos que a essas classes serão adotadas como padrão pelo ACBr, ou seja, ao invés de a opção vir desmarcada no instalador, ela vira selecionada por default. Por que estamos realizando esta mudança? Como é mencionado no tópico, consideramos que elas trazem vantagens em comparação com as classes da PCN. Depois de um período de 6 meses, com a comunidade já podendo utilizar elas e sem relatos recentes de problemas, consideramos que elas já estão maduras o suficiente para serem adotadas como padrão. Com o advento da Reforma Tributária, fica inviável manter a manutenção tanto nas classes PCN quanto nas classes ACBrXMLDocument, portanto, os novos campos relacionados a reforma foram adicionadas somente nas novas classes. Quais impactos essa mudança pode gerar? Como mencionado, essas novas classes precisam da LibXML para o correto funcionamento, portanto as dlls devem ser devidamente distribuídas junto ao executável ou estarem presentes no Path. Se você utiliza as units em sua aplicação, é provável que precise realizar a troca para evitar problemas de escopo. Por exemplo, substituir na seção uses da sua aplicação, onde tiver pcnNFeW por ACBrNFe.XmlWriter e onde tiver pcnNFeR por ACBrNFe.XmlReader.- 2 replies
-
- 8
-
-
- acbrxmldocument
- xmldocument
- (e 4 mais)
-
Mapear propriedades das classes do CT-e com RTTI
um tópico no fórum postou Gabriel Bonzanini ACBrCTe
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.