EMBarbosa

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.

Como disse antes, não é bem minha área, mas veja aí o arquivo 1-eve.xml. O retorno parece ser um erro, não concorda Ítalo? Abaixo, parte do arquivo: <soapenv:Fault> <soapenv:Code xmlns:ns1="http://xml.apache.org/axis/"> <soapenv:Value>ns1:Server.NoService</soapenv:Value> </soapenv:Code> <soapenv:Reason> <soapenv:Text xml:lang="en">The AXIS engine could not find a target service to invoke! targetService is cteRecepcaoEvento</soapenv:Text> </soapenv:Reason> <soapenv:Detail> <ns2:hostname xmlns:ns2="http://xml.apache.org/axis/">tapajos12.sefaz.mt.gov.br</ns2:hostname> </soapenv:Detail> </soapenv:Fault>

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.

Sim, você pode. Pode tentar verificar se minha teoria está correta e o arquivo xml está sendo carregado. Se o valor de EventoRetorno.retEvento.Items.Count é mesmo zero. Talvez possa entrar dentro do código do LerXml e talvez lá você consiga pegar algum erro de retorno. Também poderia verificar se há outras pessoas do seu estado tendo problemas. Além disso, podemos pedir para o Ítalo ou outro programador tentar verificar mais a fundo.

Bem, usar Currency não é opção para nenhuma variável cuja precisão passe de 4 casas. Por isso não é mesmo uma opção para esta função. O tópico não sugere isso. O tópico indicado contem dois métodos de tratamento de float para string que poderiam ser úteis ao lidar com as imprecisões do tipo de ponto flutuante. Note também que o problema não é a função FormatFloat. Ela funciona do jeito que foi projetada. Nós é que "achamos" que ela deveria funcionar de outra maneira. O tópico também possui no final um aplicativo em console para testar o comportamento de algorítimos para que possa-se validar o comportamento de maneira mais fácil.

Pelo visto o erro está no fato de não haver nenhum item no EventoRetorno.retEvento.Items. Creio que se você ligar inspecionar o valor de EventoRetorno.retEvento.Items.Count vai ser zero. Esse componente não é o que eu estou mais familiarizado mas, se eu entendi o código bem, parece que o problema está no arquivo de retorno. Veja essa parte do código logo antes do exception. Ela zera justamente esses objetos e daí lê do arquivo xml: FEventoRetorno := TRetEventoCTe.Create; FEventoRetorno.Leitor.Arquivo := FRetWS; FEventoRetorno.LerXml; Isso me leva a crer que é um problema na leitura do xml.

Tem como você durante o debug apertar o F7 nesta linha para ver onde exatamente acontece o erro?

Este tópico está duplicado:

Me parece um problema semelhante ao do LFill que foi relatado

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.

Mas creio que é isso mesmo. Na verdade, o retorno do TotalICMS na DadosUltimaReducaoZ não é retornado pelos ECFs. Ele é calculado conforme o seguinte código: // Computando Total de ICMS // if (fsTotalICMS < 0) then begin fsTotalICMS := IfThen(fsICMS.Count > 0, 0, -1) ; For I := 0 to fsICMS.Count-1 do fsTotalICMS := fsTotalICMS + fsICMS[I].Total; end; Onde fsICMS é uma lista de objetos armazenano todas as alíquotas ICMS com o tipo TACBrECFAliquota.

Acrescentando, já que é uma dúvida recorrente no fórum:

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.