EMBarbosa

Obrigado Everton. Esse daí eu não sabia ainda.

Talvez usando um emulador de portas virtuais ou, se o computador tivesse mais de uma porta física, por um cabo físico seria possível fazer o trabalho de capturar os comandos ao ECF e retornar respostas emulando um ECF. Mas provavelmente, isso não seria suficiente. Projetos como SAT/CF-e devem criar rotinas diferentes para se lidar com os dados e mostrar ao cliente. Talvez alguns dados que não são fornecidos hoje sejam necessários. Só daria mesmo pra saber depois que tudo dele estivesse certo para funcionamento e pudéssemos começar a analisar os requisitos do projeto.

Obrigado simons. Já está na revisão 3601.

O ganho de velocidade no ACBrTEFD existe. Mas como a chamada não é tão frenética, não é tão perceptível quanto no ACBrAAC. Não daria problema com o que já existe. Na verdade, o método usado quando compilado para LINUX faz o flush apenas do arquivo. O do Windows é que faz flush do Drive inteiro ocorrendo essa perda de performance. A média de chamada para o FlushFileToDisk é por volta de 26,880 milissegundos (média máxima de 55,912 milissegundos) enquanto a do FlushtoDisk é de 183,050 milissegundos (média máxima de 240,762 milissegundos).

Implementado na revisão 3597. Eu compilei aqui no Delphi XE e Lazarus e passou. Mas seria bom se outros usuários pudessem testar também. A função ACBrUtil.FlushtoDisk também é chamado pelo TACBrTEFDArquivo.GravarArquivo (definido em ACBrTEFDClass.pas). Pelo que percebi do código, também não há necessidade ser usada FlsuhtoDisk, mas apenas o FlushFiletoDisk. Se concordarem gostaria de modificar isso também.

Inclusive, acabei de perceber que o tipo para "08" está com nome errado. Deveria ser sdfEspecial e não sdfInutilizado. Corrigi na revisão 3596

Acho que não. Os Registros D200 não devem conter os fretes cancelados. Veja a nota para o campo 3 no guia prático 1.0.7 página 143:

Você utiliza o FastMM? Caso negativo, use o no seu projeto. Ele é tão importante que se tornou padrão nas versões mais recentes do Delphi. Postei sobre ele num erro parecido aqui. Daí você nos dê algum retorno.

Ah. Então o erro podia ter sido causado mesmo pela falta de memória, mas o erro era do OLE e não do componente. "Out of Memory", realmente deve ser do componente com uma base de dados grande. Eu precisaria de um exemplo para poder analisar melhor. Sei que outro usuários do fórum já passaram por isso. Talvez algum possa ajudar. Só por via das dúvidas, qual a versão do Delphi usado nesse projeto?

Não acho que o erro seja no componente em si. Mas sem os códigos que geram o erro é muito difícil dizer o que pode ter causado. A mensagem parece com erro de objetos OLE. Talvez uma conexão com o Banco de Dados usando drivers OLE?

Que bom. Obrigado por postar como resolveu.

Tente verificar como está no DEMO que funciona e colocar no seu também.

Configurações no dproj ?? talvez as configurações de projeto (Menu Project -> Options ->)

Olhe aí na linha 32 a definição do TForm. Se o Build ALL dá erro, Não tem sentido. :S Faz mais um teste: Apague o arquivo ACBrECFTeste.bdsproj, Daí abra o projeto usando o ACBrECFTeste.dpr Verifique se você consegue achar algum arquivo Forms.dcu nas pastas do DEMO

Pelo visto, o Delphi está achando units do Delphi compiladas (*.dcu) em outros lugares. Afinal ele reclama que não achou o identificador TForm, mas ele foi definido na unit Forms, na cláusula uses e ele não reclamou não ter encontrado essa unit. Será que não existe em alguma pasta essa unit (Forms) que era parte de outro projeto? Faça um Build ALL do projeto. Se continuar a dar erro, tente o seguinte: abra a Unit ACBrECFClass.pas vá na linha 51. Selecione a palavra Forms. Clique com o botão direito e escolha "Open File At Cursor" Veja qual arquivo Forms.pas o Delphi abre

Vou fazer a modificação no SVN então.

Esse BioShop usa forms? Se sim, apague os arquivos ECFTeste.dproj.local e ECFTeste.dproj. Abra o arquivo ECFTeste.dpr para averiguar se não é nenhuma configuração no dproj.

agora faz o mesmo usando um outro projeto qualquer que não faça uso do ACBrECF no Delphi 2006

Se funcionou no Delphi 7 o problema não parece ser do componente mas da instalação realizada no seu Delphi 2006, concorda? 1) Por favor, faça um printScreen da tela incluindo a mensagem de erro do Delphi 2006. 2) Depois abra um outro projeto no Delphi 2006, compile e faça um printScreen também.

Esqueci de mencionar outra vantagem, é que o FlushtoDisk pode pedir privilégios administrativos, mas o FlushFiletoDisk não.

Para corrigir a situação, eu sugiro criar uma função FlushFiletoDisk no ACBrUtil.pas e fazer o ACBrAAC chamar essa função ao invés da atual FlushtoDisk. Assim, se algum outro componente precisar do Flush no Drive pode continuar usando a atual chamada, mas o AAC não vai ter perda de performance por causa disso. Quase 9 (nove) segundos numa venda de apenas 53 itens ao meu ver, é um tempo considerável. E isso pode ser muito maior dependendo do número de arquivos abertos/alterados por outros programas mas que não tiveram seus buffers gravados no drive. O que acham?

Se seguir a mesma ideia do imComDados e imSemDados, será manualmente. Mas não está definido ainda.

Você consegue compilar alguma outra aplicação? Um projeto que venha como exemplo no Delphi talvez?

Sim, é necessário a DLL. O motivo, de forma resumida, é que os fabricantes de ECF não disponibilizaram como fazer isso via protocolo, apenas utilizando a DLL deles.

Olá, rapaz não posso acessar o messenger daqui. Você verificou se o erro acontece com outros projetos também, como o DEMO do ACBrTEFD?