EMBarbosa

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  37885.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela, mas com algumas modifiações. Notei que seus arquivos parecem bem desatualizados.
Subi as alterações para o SVN na Revisão  37551.
Pelo que vi está tudo certo, mas queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

@Onclick A alteração para os valores 15 e 75 já estão no SVN desde 10/2024.
Mas de acordo com o site do Sintegra, também deveriam ser incluídos os 76, 77, 78 e 79. Adicionei isso.
Vejam: https://www.sintegra.gov.br/Cad_Estados/cad_PA.html
Revisão SVN 73222

Muito obrigado pela contribuição.
Fiz a implementação baseada nela. Mas fiz uma alteração para garantir que se alguém estiver utilizando um arquivo anterior em cache continue conseguindo ler os dados.
Acredito ter coberto todos os pontos, mas por favor, queira atualizar, testar e reportar qualquer problema.
Subi as alterações para o SVN na Revisão  37224.
Mais uma vez obrigado.

A contribuição no tópico citado post acima foi enviada ao SVN, conforme mensagem citada abaixo:
Assim, estamos fechando essa TK-5132 até segunda ordem.
Se for necessário uma nova análise, fiquem a vontade a postarem novas mensagens.
Nota: ainda estamos aceitando contribuições para o aplicativo de exemplo. Vejam o tópico citado.

Apenas para ficar registrado, o problema foi resolvido utilizando o FastMM 4, trocando o gerenciador de memória nativo do Delphi 7.

Muito obrigado pela contribuição.
Mas achamos melhor corrigir a função. Pelo visto, ela não era usada no código do ACBr em outros lugares e estava incorreta já faz um tempo.
@ddsilva,
Subi as alterações para o SVN na Revisão  32926.
Pelo que vi está tudo certo.
Pedimos a todos o favor de atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado a todos pelo relato e sugestões de correção.

Olá Renan, tudo blz?
   Isso não tem nada a ver com o problema, mas veja a seguinte informação: https://acbr.sourceforge.io/ACBrLib/CdeclouStdCallqualusar.html
   Você deve escolher o que for compatível com seu sistema e "ambiente destino" (aonde o sistema for executado).
 Essa parte do código não me parece fazer nenhuma referência ao INI. Se fizer, me desculpe, pois node.js não é minha especialidade. Mas me aponte exatamente qual linha faz isso.
 
A princípio, me parece que você está utilizando um mesmo arquivo escrito anteriormente. O arquivo .INI deve ter sido salvo no HD e, é claro, reiniciar a máquina por si só não vai apagar o conteúdo dele.
Verifique no seu código onde você passa o arquivo .INI qual o caminho. Daí veja se o arquivo já não está salvo no HD.
 

Vocês estão equivocados. A última versão é a versão 5.1.0. Segue o print do link que enviamos pra vocês.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi essas alterações para o SVN na Revisão  31699.
Essas alterações não enviei ao SVN. Porque esses campos nos registros M100 e M500 podem ser nulos e podem ser zero.
Então precisamos das funções VDFILL ou VLFILL para tratar o caso dos campos nulos mas não são zero.
Você pode até reparar que o tratamento da função VDFILL e DFILL para máscara de decimais é o mesmo e só muda o tratamento para campo "nulo".
Além disso, eu fiz um teste aqui usando o exemplo do ACBrSpedPisCofins e o código funcionou normalmente. Veja na imagem:

 

Muito obrigado pelas contribuições.
Não enviei ao SVN a remoção do campo MUN do registro 1400. Esse campo continua no layout.
A diferença pelo que parece, é que agora pode se informar o registro sem esse campo, de acordo com o que a UF decidir.
Assim, adicionei uma validação para adicionar o campo apenas se estiver preenchido.
---
@DevCriare
Muito obrigado pelas contribuições que enviou no Discord. Juntei com as alterações acima para fazer o merge.
Algumas alterações propostas eu não enviei ao SVN.
Por exemplo: Não me parece correta a alteração para não gerar os registros C855 C895 no layout "vlVersao116".
Note que a possível obrigatoriedade em 2024, não implica em impossibilidade de informar em 2023.
Isso também acontece com o registro 0221, cujo manual diz o seguinte: (grifo meu indicando a possibilidade de informar o registro em 203)
Se vocês não concordarem por algum motivo, por favor, esclareçam seu raciocínio.
---
Além de outras alterações que eu fiz no código, também fiz o seguinte que pode ser útil pra vocês analisarem:
- Alteração nas funções StrToTpResido, TpResidoToStr, CodVerToStr e StrToCodVer para um modelo de conversão de enumerado que é recomendado no código ACBr atualmente.
- Remoção de with em funções que mexi;
----
Mais uma vez obrigado a todos pelas contribuições.
Fiz a implementação baseadas nelas.
Subi as alterações para o SVN na Revisão  31662.
Pelo que vi está tudo certo.
Queiram por favor atualizar, testar e reportar qualquer problema.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  31581.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.
 

@CrasH, @Tiago Domingues Carneiro, @Dor_poa,  e outros
Subi no SVN uma correção.
Deve estar tudo ok agora.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  31107.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.

Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  29900.
Pelo que vi está tudo certo, mas queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Olá... já respondemos você em outro tópico. Veja:
 
 

Bom dia.
Pode deixar que vamos analisar a questão dos logs não serem gerados na pasta configurada.
Esse é o problema maior. Não temos esse ambiente pra testar e avaliar a situação. Precisamos disso. Nesse caso, você pode:
1) montar uma VM e disponibilizar pra nós para conseguirmos reproduzir
2) procurar ajuda com pessoas que são especialistas em linux e no ambiente que você montou para obter mais informações sobre o motivo.
 

Respondido em:
 

Respondido em:

Cdecl e StdCall são "convenções de chamadas de funções" e você deve usar de acordo com a programação da sua linguagem ou Sistema Operacional.
Já a versão MT, é a lib preparada para MultiThread. Use ela se você for programar com esse objetivo.
Existe esse projeto no GitHub criado pela comunidade em Python. Talvez possa ser útil:
https://github.com/base4sistemas/acbrlib-python

Olá,
Vamos lá...
Só pra deixar claro e sem ambiguidade, nesse contexto, o "CTD" significa "Crash to Desktop", certo? Se for isso, eu acredito que o que está acontecendo é que uma exception não foi tratada da maneira que deveria. Com isso a aplicação se perdeu.
Uma exception sem mensagem não é muito comum nos códigos do ACBr. Precisamos obter mais informações.
Você consegue testar com o utilitário ETQTeste? Link logo abaixo.. Configure ele para gerar o Log e anexe o log aqui pra nós.
Se funcionar nele, então deveria funcionar na LIB.
 
É importante também verificarmos com detalhes a LIB.
Então, anexe também o log da ACBrLib para gente verificar até onde ela foi sem erros. Coloque o log no nível paranoico por favor.
Outra coisa importante é procurar no Visualizador de Eventos do Windows que informações estão disponíveis sobre o crash de sua aplicação.
A tela é mais ou menos assim:

As informações que estão ali nas abas "Geral" e "Detalhes" podem ajudar no diagnóstico.
Eu notei que seu código está dentro de um Event Handler. Não sou especialista em C# nem tenho todo o seu códig, mas há uma possibilidade de isso afetar a forma como a aplicação responde. Veja por favor se faz algum sentido o seguinte link: https://stackoverflow.com/a/66163636/460775
Uma outra possibilidade é você atribuir o evento Application.DispatcherUnhandledException. Por meio dele você consegue fazer um log, talvez até um callstack na sua aplicação do momento em que ela crashou.
Essa já é uma pergunta que você deve levar a pessoas mais experientes no C#. Talvez algum fórum específico de C#.
EDIT:
Só pra deixar claro, a chamada ativar deveria ser apenas uma chamada à lib (uma dll). Assim, teoricamente, nada "externo" deveria influenciar.
Por outro lado, se a exception gerada pela lib está saindo "fora do lugar", talvez o que está "externo" influencie o como ela está sendo tratada.

Muito obrigado pelo report.
Fiz a correção e subi as alterações para o SVN na Revisão  29087.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.

Só pra ficar claro pra alguém mais que encontrar esse tópico: PPLZ é o mesmo que linguagem ZPL, que é diferente de ZPLII (ou ZPL2).
Infelizmente ZPL2 não é compatível com a ZPL, por isso não funcionou.

Muito obrigado pela contribuição.
Fiz a implementação baseada nela.
Subi as alterações para o SVN na Revisão  28949.
Pelo que vi está tudo certo.
Queira por favor atualizar, testar e reportar qualquer problema.
Mais uma vez obrigado.