Daniel Simoes

Sim, certamente há consumo de memória... mas é apenas Texto... e adicionar novas linhas no Memo não levará mais Tempo quando o mesmo estiver grande... Se vc não re-inicia nunca essa máquina isso pode ser um problema com o passar de alguns meses... e (ainda) não há um comando que zere o Memo... Outra coisa é o LOG em disco... para esse existe um parâmetro que limita o numero máximo de linhas... e ele é verificado a cada inicialização do Monitor

Se vc está iniciando o desenvolvimento em TEF discado... recomendo uma Leitura completa e atenta do Manual do Gerenciador Padrão antes de prosseguir...

Ele não precisa retornar nada.... Assim como todos os comandos, ele retornará OK: se teve sucesso ou ERRO: se falhou

Não compreendi corretamente o que vc quer limpar... é o texto que aparece no Memo ou o arquivo de Log ?? Não... isso não causará lentidão... provavelmente é outra coisa...

A pergunta não parece fazer muito sentido.... mas tentando responde-lo: NFe pode ser impressa em qq impressora...

Estude os fontes do projeto Demo... Está tudo lá... veja: procedure TForm1.AliquotasICMS1Click(Sender: TObject); var A : Integer ; begin ACBrECF1.CarregaAliquotas ; for A := 0 to ACBrECF1.Aliquotas.Count -1 do begin mResp.Lines.Add( 'Aliquota: '+IntToStrZero( ACBrECF1.Aliquotas[A].Sequencia,2)+ ' Indice: '+ACBrECF1.Aliquotas[A].Indice +' -> '+ FloatToStr( ACBrECF1.Aliquotas[A].Aliquota ) + ' Tipo: '+ ACBrECF1.Aliquotas[A].Tipo ); end ; mResp.Lines.Add('---------------------------------'); end; [/code]

Oi Rafael, Obrigado pela contribuição.... - Em relação a primeira modificação... Atualmente o fonte de TEFDClass já está ligeiramente diferente, e foi alterado pelo mesmo motivo... - Em relação a segunda modificação, que tenta fechar o relatório em caso de Falha, tenho receio de que ela quase nunca funcione... Veja: Se o relatório falhou, é porque o ECF se encontra em condição de Erro... primeiro devemos dar um aviso ao usuário, que deverá tentar corrigir a situação de erro, e dai sim, temos condições de tentar imprimir algo mais (fechar o relatório)... Vale lembrar que o TEFD sempre verifica o estado do ECF antes de iniciar a Impressão de qualquer Relatório Gerencial ou Vinculado, fechando os relatórios anteriores se necessário... O que você acha ? Essa alteração foi mesmo necessária ? Ela foi um pre-requisito para a sua homologação ?

Bacana.... acho que com a sua ajuda, conseguiremos promover o ACBrCNAB da Branches para a Trunk.... Por favor entre em contato com o ItaloJR, e verifique quais tarefas precisam ser completadas ou melhoradas

Veja a pasta: ACBr\Exemplos\ACBrTEFD

SIM... isso mesmo.. bem lembrado

Sem problemas... desculpe-me se pareci "rude"... (não foi essa a intenção)... Acho que com uma imagem as coisas ficam mais claras

Quem iniciou o AcbrCNAB foi o Italo Jr (mantenedor do ACBrCTe) Para falar bem a verdade... eu não compreendo muito bem a diferença do ACBrCNAB e dos arquivos de Retorno e Remessa gerados/mantidos pelo ACBrBoleto... (mas tb não li muito sobre o assunto)

O problema de abortar o programa ocorre igualmente com o Demo do TEFD ? Se SIM... favor fornecer passos detalhados para reprodução do problema

Nós é que agradecemos.... Obrigado Carlos, pela sua plena disposição... Tenho acompanhado seus posts, e notei que você tem sido de grande ajuda na elaboração e suporte do ACBrBoleto...

Parece ser algum bug na sua aplicação... ao chamar o NCF ou CNC... varios eventos do ACBrTEFD são disparados... o problema pode estar no seu código dentro do eventos... Teste com o Demo do TEFD e verifique o correto funcionamento...

Oi Gabriel... a quanto tempo... Também sou fá do THalcyonDataSet... é o único que abre corretamente os arquivoc DBF/CDX do xHarbour / Clipper Consegui porta-lo para Lazarus / FPC se alguém que tiver uma licença válida, desejar, posso enviar os fontes...

Não é essa informação que é necessária para a analise... Precisamos do LOG DO ECF e nao do ACBrMonitor Por favor leia com mais atenção minhas mensagens anteriores...

Acho que as principais mudanças serão no suporte a Impressão de Boletos, usando o ACBrBoleto... No demais apenas pequenos ajustes, para bugs muitos específicos...

Apenas com o LOG gerado pelo ACBrECF poderemos saber o que exatamente o ACBrECF leu do ECF...

Uma resposta bem mais adequada para o caso da "LeituraX" viewtopic.php?p=2612#p2612

Rossine, vc pode criar um passo a passo para a reprodução do problema ?

Provavelmente vc precisa aumentar o TimeOut.... No meu caso, não trato a ReduçãoZ com try/except... pois o tempo pode variar muito de acordo com o ECF e com o movimento do usuário... Comando a RedZ e depois analiso o Estado do ECF... se ele estiver em estBloqueado a RedZ foi emitida com sucesso...

Basta vc programar algo no Evento ACBrECF.OnMsgPoucoPapel, que o ACBrECF não emitirá mais a msg O valor é de quantos em quantos segundos o ACBrECF verifica pela proximidade do fim do papel (pouco papel, e não fim de papel) O problema é realmente no sensor do ECF... Geralmente os ECFs da Bematech precisam de um ajuste no sensor da bobina... o até mesmo, inutilizar esse sensor com uma fita isolante, ou algo parecido

Acho que esse comando não foi implementado... Nunca vi a utilidade desse comando... lembre-se que o Cupom Adicional não é uma copia do Cupom anterior

Parece que elas foram realmente programadas com o "V" na frente... Por favor tente colar aqui uma imagem da Leitura X deste ECF... Mas esse é o LOG gerado pelo ACBrMonitor... copie aqui o LOG gerado pelo ACBrECF (veja na aba ECF do Monitor)