EMBarbosa

O registro C114 é filho do C110. Você está criando os registros C110 antes? Não consegui reproduzir seu problema com o Demo do ACBrSPEDFiscal. Você fez alguma alteração no código do Demo para testar? Queira disponibilizar para que eu possa averiguar.

Vai ser necessário fazer uma limpeza no seu computador e reinstalar o ACBr. Siga os passos delineados

Você vai precisar usar o debug, usando o F7, e descobrir qual exatamente a linha do método RegistroC114New onde acontece esse problema.

Infelizmente, sem as exatas alterações que eu pedi e sem os logs eu não tenho como aprofundar mais nesse problema até que consiga um ECF físico e tempo para testar...

Bem, eu não tenho um ECF destes aqui para testar... Por favor, faça as alterações que eu sugeri, faça o build e anexe o log depois de cada alteração. Tenha certeza de que só as alterações que eu sugeri estão no código.

Olá EddieBr, Vou pedir para que você faça dois testes. Vou apontar onde você vai alterar no código e vamos ver o comportamento se melhora ok? Você deve fazer o seguinte. Faça uma alteração primeiro. Faça Build dos componentes. Faça o Build do ECFTeste. Faça o teste. Anexe o log. Faça a outra alteração. Faça Build dos componentes. Faça o Build do ECFTeste. Faça o teste. Anexe o log. Aqui vão: Arquivo ACBrECFClass.pas, método TACBrECFClass.DoLeResposta (por volta da linha 1851), aumente o timeout do fpDevice.LeString de 100 para 2000, conforme abaixo: Fim := True ; if not FimLeitura then begin Fim := False ; try fpRespostaComando := fpRespostaComando + { Le conteudo da porta } fpDevice.LeString(2000) ; // ALTERADO AQUI !!!!! // fpDevice.LeString(100) ; // ESTAVA ASSIM!!!!! Segunda e Terceira Alteração são no arquivo ACBrECFBematech.pas. Método TACBrECFBematech.VerificaFimImpressao, por volta da linha 1044. Veja abaixo: try GravaLog(' '+FormatDateTime('hh:nn:ss:zzz',now)+' VerificaFimImpressao: Pedindo o Status (19)' ) ; fpDevice.Serial.Purge ; // Limpa buffer de Entrada e Saida // fpDevice.EnviaString( Cmd ); // Envia comando // // espera ACK chegar na Porta por 1,5s // wACK := fpDevice.LeByte( 3000 ) ; //ALTERADO AQUI !!!! // wACK := fpDevice.LeByte( 1500 ) ; //ESTAVA ASSIM !!!! if wACK = 6 then // ECF Respondeu corretamente, portanto está trabalhando // begin GravaLog(' '+FormatDateTime('hh:nn:ss:zzz',now)+' VerificaFimImpressao: ACK = 6, OK... Aguardando ST1 e ST2' ) ; TempoLimite := IncSecond(now, TimeOut); fsFalhasFimImpressao := 0 ; // Aguarda ST1 e ST2 por mais 2 segundos // RetCmd := fpDevice.LeString( 4000, 2 ) ; // ALTERADO AQUI!!!!! // RetCmd := fpDevice.LeString( 2000, 2 ) ; // ESTAVA ASSIM !!!! Result := (Length( RetCmd ) >= 2) ; end else raise EACBrECFErro.Create( 'ACK <> 6' );

O que a está escrito na wikipédia é justamente o que eu escrevi ali acima. O documento que eu citei tem uma explicação mais profunda. A propósito, esse é um problema de qualquer linguagem. O que acontece é que algumas tem uma precisão maior, então pode ter passado despercebido. Claro, a forma como o compilador trata as variáveis e as constantes também pode influir. Mas sempre haverá o problema da imprecisão por se tentar representar um conjunto infinito de números num espaço limitado de memória ou seja um conjunto finito.

Apenas para explicar, as dlls devem ser de acordo com o aplicativo que fará as chamadas e não com o sistema operacional. Assim, se o aplicativo é 32 bits, mesmo estando instalado em um sistema operacional de 64 bits, as dlls devem ser 32 bits.

Talvez alguma incompatibilidade do Delphi 2010 com o Windows 8.1 64 bits.

Que problemas? Poderia ser mais específico? Qual o comportamento que você esperava? Qual o comportamento que encontrou?

Daria pra reproduzir o cabeçalho do arquivo de log deste teste no ECFTeste? Informe outros parâmetros também (Intervalo entre comando, por exemplo). Parece que o timeout é pequeno.

Veja

Na verdade, a princípio, você não deveria fazer esse tipo de comparação. É para isso que existem as funções como SameValue, CompareValue, IsZero na unit Math do Delphi (e Lazarus). Daniel, provavelmente o que você quer é algo mais parecido com o What Every Computer Scientist Should Know About Floating- Point Arithmetic. De forma resumida, o que acontece é que, como existem números infinitos e memória limitada, alguns números não são possíveis ser representados. Então para esses números os valores são armazenados internamente com uma aproximação. Então, dependendo do valor, temos que lidar com uma aproximação. Tem outro tópico no fórum onde teremos que lidar com um problema semelhante devido as peculiaridades dos pontos flutuantes. Inclusive com código para teste. Finalmente, essas diferenças são o motivo de muitas pessoas aconselharem a trabalhar com o tipo Currency para valores monetários ou onde não se pode perder a precisão. O tipo Currency não é armazenado como um float, mas como de ponto fixo (mais precisamente como um int64). O problema é que nesse caso, ele possui um número de dígitos significativos limitado, não sendo possível expressar nenhuma diferença entre valores fora de sua precisão (que é 4). Assim, para os valores Currency, não há diferença entre 1,12345678 ou 1,12348765.

Olá Poliany, você tentou ler o log? Tem alguma informação a mais? Poderia anexar o log?

Parece que o comando que pega o NumLoja não foi pego no log. Poderia verificar se faltou chamar esse refazendo os passos?

Esse é um erro fatal originado por um outro erro. Você precisa postar a mensagem completa de erro especialmente com os erros imediatamente anteriores a esse, para sabermos o que aconteceu.

Isso não deveria fazer diferença. Pelo contrário, evitar o uso do ProcessMessages pode até corrigir alguns problemas relacionados com comandos paralelos mesmo. Você consegue fazer um teste usando o demo em Delphi disponibilizado pela Bematech?

Acho que você esqueceu o Log.

Tenta o fazer ACBrECF.Device.ProcessMessages := False;

Você consegue verificar se a porta está marcada como serial no código? Veja que no código do TACBrDevice.LeByte, ele acessa a propriedade IsSerialPort. Em caso negativo, pode ser algum problema no código da HookLeString. Mas se essa propriedade IsSerialPort for verdadeira, ele chama o RecvByte. Essa parte do código daí pra frente já é de responsabilidade do projeto Synapse. De qualquer forma, eu fui tentar dar uma olhada e o callstack após o LeByte que considera o TimeOut é mais ou menos esse: function TACBrDevice.LeByte(ATimeOut: Integer): Byte; function TBlockSerial.RecvByte(timeout: integer): byte; function TBlockSerial.RecvPacket(Timeout: Integer): AnsiString; //É aqui que é chamado a Exception ESynaSerError Communication error 9997 function TBlockSerial.CanRead(Timeout: integer): boolean; // Quando essa função não retorna, gera o erro 9997 function TBlockSerial.CanEvent(Event: dword; Timeout: integer): boolean; //Usa o TimeOut para chamar a função abaixo: WaitForSingleObject(Overlapped.hEvent, Timeout); //API do Windows; Bom, exceto se eu tiver despercebido algo, no final das contas, a responsabilidade para verificar se o timeout foi alcançado é do WaitForSingleObject que é uma API do Windows em geral muito confiável. Seria bom verificar se essa parte do código está sendo chamada e o TimeOut está correto nela. É importante lembrar que se estiver debugando, o tempo que Delphi para pra que você possa responder a esse tipo de exception é contado no TimeOut. Logo, se estiver debugando e essa exception for levantada e você não a responder rapidamente, isso vai gerar erro como se o ECF não tivesse respondido.

Subi suas alterações para o SVN na Revisão 6974. Pelo que vi está tudo certo. Favor testar e reportar qualquer problema. Obrigado.

Claro. Se não pudesse, pra que serviria a outra tabela?

é que eles estão usando Git agora e não o SVN.

Ou seja, no Delphi XE vai fazer uso da interface IWebBrowser2 disponível na SHDOCVW.DLL. Se esta dll estiver incorreta, pode ser esse o problema ou talvez a versão do seu Delphi seja antiga. Qual a versão do seu Delphi e sistema operacional?

O TWebBrowser é na verdade o IE instalado na máquina. Então basta atualizar o IE da máquina.