EMBarbosa

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?

Por favor, reformule seu post. Ele não dá informações necessárias sobre o problema. Você até se contradisse: Título do post:Bloco P Não está imprimindo no txt Primeira frase do post:Bloco p está imprimindo no arquivo TXT

Por favor. Dúvida nova, tópico novo. Tópico dividido.

Pelo seu post, acredito que sim. Mas passei por uma certificação TEF a pouco e estamos nos preparando para homologação PAF-ECF. Por isso e outras coisas não tive o tempo necessário para averiguar suas alterações ainda. Devo analisar ainda essa semana e deixo uma resposta aqui mesmo. E mesmo que não eu, outro desenvolvedor ACBr pode fazê-lo. Obrigado pelas sugestões.

Não tenho certeza do funcionamento ou não do parâmetro NumCOOInicial. Me desculpe não poder confirmar isso agora. Sugiro entrar em contato com a Bematech e ver o que eles dizem fazer. Daí nós podemos ter certeza do que devemos fazer. Se fizer do jeito que mencionou, a primeira Redução Z você vai ter que configurar "na mão".

Olá, Pode explicar qual o objetivo das alterações?

Então, quando você for preencher os dados, não adicione registro 75 de um produto que não foi movimentado no período do arquivo Sintegra, ou, se isso não for possível, remova os registros 75 dos produtos que não foram movimentados no período do arquivo. Não utilizo o WinMFD2 para esse tipo de trabalho, então não posso lhe dar mais detalhes sobre como fazer. Talvez algum outro usuário, ou o fórum da Bematech. Mais uma coisa: Esse subfórum é para dúvidas relacionadas com os componentes ACBrSintegra/ACBrPAF. Estou movendo seu post para área de Dúvidas Gerais.

Não vai dar para postar os testes todos hoje, então abaixo eu deixei um teste simples. Também anexei o programa (em Delphi) que estou usando para fazer o teste dos tempos juntamente com o arquivo AAC alterado, com a opção para tanto o comportamento atual (efetuar flush do Drive) como para efetuar o flush apenas do arquivo. Assim todos podem testar nas suas próprias máquinas. Poderão perceber que ele permite atualmente 2 métodos de medição e impressão dos itens e 1 sem nenhum método, para ser usado com um profiler externo. TesteVelocidade.rar

Como ou que código você está usando para gerar os registros 50?

Quando chamamos a função Apenas para o arquivo, o retorno é praticamente instantâneo. Vou colocar abaixo a função, mas antes de alterar o componente, vou postar amanhã pela manhã resultados dos testes. Daí se todos tiverem de acordo posso fazer a alteração. procedure EfetuaFlushArquivo(const nomearquivo: String); var hFile: THandle; bResult: boolean; lastErr: Cardinal; filenome: string; begin bResult := False; filenome := '\\.\' + nomearquivo; //Para usar a versão Wide da função CreateFile e aceitar o caminho completo do arquivo hFile := Windows.CreateFile( PWideChar(filenome), GENERIC_READ or GENERIC_WRITE, FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL or FILE_FLAG_WRITE_THROUGH or FILE_FLAG_NO_BUFFERING, 0); bResult := FlushFileBuffers(hFile); CloseHandle(hFile);[/code] Só chamando a atenção, que todos os componentes que no momento usam o ACBrUtil.FlushToDisk, na verdade estão fazendo o Flush do Drive inteiro e não do o arquivo passado por parâmetro.

Seu erro não tem relação com o erro relatado pelo FTGK!. Favor criar um tópico novo para dúvidas diferentes.