EMBarbosa

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

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:

MODERAÇÃO: Esse tópico é muito antigo e não temos como saber de forma eficaz quem participou nele que ainda está envolvido atualmente com o assunto. Assim, estamos fechando o tópico. Os interessados nesse assunto, por favor, criem novos tópicos.

Para quem quiser ver como estamos usando o FPDF no ACBrBoleto, veja essa notícia publicada anteriormente:

Interessante que não é detectável na aplicação em C#. Em outras linguagens parece não acontecer. Você tem o log da lib desse caso? Preciso verificar no código outra vez, mas pode ser que se você chamar um comando de impressão, a lib ative o componente automaticamente. Geralmente as aplicações preferem usar os métodos ATIVAR e DESATIVAR porque, enquanto ativo, a aplicação prende a porta serial de comunicação com a impressora. Outro detalhe é que alterar a propriedade "Ativo" no INI para "1" pode ter o mesmo efeito de chamar o método ETQ_ATIVAR.

Acredito que seja a situação de comunicação com a impressora de etiquetas. Por exemplo, essa propriedade deve marcar "1" depois de chamar o método "ETQ_Ativar", indicando que a comunicação com a impressora foi estabelecida. Que bom que resolveu. Por outro lado, você consegue detalhar um passo a passo de como reproduzir? Assim a gente ficar pode analisar e orientar os próximos usuários que passarem pelo problema.

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.

Procure por placas PCI com portas USB.

Existem muitas soluções na internet como APIs do Google, Bing Maps e alguns projetos OpenSource para calcular rotas. Eu nunca usei nenhuma delas, mas pesquise por "routes API calculate" que você encontra algumas opções. Mas daí fazer cálculo de divisões de rotas e entregas (que é similar a resolução do "problema do caixeiro viajante"), talvez já complique um pouco. Talvez tenha alguma ideia pesquisando em como grandes empresas de transporte estão fazendo hoje.

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. 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?