EMBarbosa

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?

Olá Filipe, Eu fiz algumas alterações baseadas no sua sugestão. Além do que você postou eu adicionei também a versão 2.0.0 e criei o tratamento específico para a versão de layout 2.0.1 mencionado no Guia Prático Contribuições 1.0.7. Removi assim o tratamento para os layouts anteriores no que se refere ao CAMPO 05, visto que agora temos na documentação claramente que eles não devem aparecer. EDIT: revisão 3592.

Olá edilson, Em primeiro lugar, gostaria de lhe agradecer pelas sugestões. É bom termos usuários que participam. É o que garante o sucesso do projeto. Mas seria bom ter um pouco mais de consideração. Não sei com que moderador está falando, mas tome um pouco mais de cuidado na escolha de palavras. Evite passar a impressão que você tem o direito de exigir alguma atitude de moderadores e desenvolvedores. Lembre-se que você não paga pelo auxílio, pelos códigos que já recebeu, pelo fórum, etc... Agora, voltando para a sua sugestão. Atualize seu código pelo SVN e anexe o código atualizado por favor. Seu código é baseado numa revisão e isso dificulta saber o que é que você alterou e o que não é. Mais uma vez, obrigado.

Olá Rubens, Acho que você confundiu-se. O TortoiseSVN que você vai fazer o download nesse link que postou é para fazer o download do ACBr, e não o próprio ACBr. O projeto ACBr usa um controle de versões de código chamado Subversion (abreviado para SVN), cujo protocolo permite o download e atualização utilizando o TortoiseSVN. Não há problemas possuir o TortoiseSVN 64 bits, pois ele só é usado para fazer o download dos códigos no SVN. Na hora que compilar será usado o que você definiu no seu projeto. Para facilitar a instalação por iniciantes do projeto foi criado um programa para isso. Veja o seguinte link: ACBrInstall

Subi na Revisão 3591. Obrigado pelo report.

Eu fiz uma correção um pouco diferente na revisão 3590. Gostaria que pudesse testar e dar um retorno. Obrigado.

Isso acontece só com sua aplicação ou com os programas de exemplo do ACBr também?