EMBarbosa

Você sempre pode olhar o blame do SVN para verificar quando o código foi adicionado. Talvez lá tenha mais informações, como é o caso: E como nesse mesmo caso, talvez não seja ainda suficiente. Mas o arquivo em anexo no tópico citado pode dar uma ideia.

Respondido em:

Respondido em:

É assim mesmo que funciona. Pesquise mais sobre concorrência de transações e isolamento de transações.

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. Subi as alterações para o SVN na Revisão 29115. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Em tempo, essa alteração está relacionada ao seguinte tópico:

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.

Realmente, está acontecendo no Lazarus também. Não consegui um tempo pra verificar o que ficou pra trás. Assim que der vamos verificar não só esse mas alguns outros componentes que estão na mesma situação.

Pessoal por favor, continuem qualquer discussão no tópico linkado. Vou fechar esse pra diminuir o volume de informações separadas.

Relacionado?

Olá pessoal, novo componente na área. O ACBrSIN foi feito para se comunicar com sinalizadores ou sinaleiras de Self-Checkout. Ele foi contribuído pelo colega @Warquia Pereira, no seguinte tópico: Nesse tópico tem até um vídeo de algo que pode se fazer num Self-Chekout. Valeu Warquia! A princípio está implementado a comunicação com a marca Laurenti. Mas facilmente pode ser feito para outras marcas e modelos já que a comunicação é serial. Fiquem a vontade para usar o fórum para feedbacks ou quem sabe até continuar ajudando no desenvolvimento. Bom trabalho por aí!

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.

Você consegue visualizar o conteúdo dos dois de alguma maneira? Por exemplo usando o IBExpert? Se conseguir, você pode comparar.

Me parece que não... Quando eu li pela primeira vez, acho que não atentei a essa frase direito: Tecnicamente, os dois são um arquivo XML. Isso indica que há um problema nos dados e não na maneira que você usa para extrair os dados. Os dois documentos podem ser armazenados da mesma maneira. Mas será que estão sendo? É possível que os CFe não estejam sendo salvos da mesma maneira que os NFe. Verifique se os CF-e estão realmente no Banco de dados igual aos arquivos NFe.

O que isso quer dizer?

Muito obrigado pela contribuição Adicionei no nosso backlog (#TK-3751). Assim que possível daremos um retorno.

me parece que é algum problema com a pasta de schemas. Talvez exista algum schema faltando ou desatualizado.

@Jéter Rabelo Ferreira, mais uma vez, muito obrigado por nos avisar. Adicionei no nosso backlog (TK-3712). Assim que possível daremos um retorno.

Oi Jéter, tudo blz? Você tem mais de um Delphi na máquina? Quais as opções que você marca no ACBrInstall?

Por favor, não fique pingando todo mundo que você conhece sem a autorização dos mesmos. Principalmente os consultores e moderadores. Isso não é legal. As pessoas podem começar a te ignorar por fazer isso. Se precisa de um atendimento mais rápido considere juntamente com sua empresa assinar o ACBr Pro. Com respeito a tal alteração: Precisamos de mais informações. Onde está a documentação atualizada? Há exemplos de arquivos? Também precisamos saber se isso é apenas para uma cidade ou para todas que o provedor atende. Quais cidades? Pode ser que sim. Mas precisamos das informações que eu citei antes. Qual a mensagem de erro?

Olá. Até onde eu consegui identificar, a maior diferença nesse seu dfm para o que está no SVN é a propriedade "PixelsPerInch". No seu dfm está configurada como 96. No nosso, ela usa o valor padrão (vazio). Não podemos subir isso porque essa é uma configuração específica para cada monitor/impressora/etc... e também pode ser influenciado dependendo da configuração no "manifesto" da aplicação. Essa configuração então é feita nas propriedades que você já citou... Mais informações abaixo. Os valores padrões realmente são esses. Já eram antes de atualizar o ACBr e atualizar ele não faz qualquer quebra no layout a menos que você modifique essas propriedades. No entanto, isso não quer dizer que funciona em toda ocasião. Se esse fosse o caso, não teríamos criado essas propriedades há anos atrás. Conforme dito anteriormente isso depende de vários fatores: 1) versão do Fortes Report 2) configurações da sua aplicação (manifest) 3) configurações do Windows (ou monitor) . Não quer dizer que esteja com problemas. Você deve fazer a configuração conforme a máquina que estiver executando o aplicativo. Não coloque a configuração amarrada na sua aplicação. Se isso não for configurável em sua aplicação, você terá problemas na impressão. Além disso não deve ser uma configuração arbitrária e sim a configuração correta para aquela máquina/monitor/impressora.

https://projetoacbr.com.br/cursos/sat-sp/