EMBarbosa

Basicamente é assim: Se você vai usar herança, então não precisa copiar as units. Se você vai criar um componente diferente onde os métodos precisarão ser alterados então você faz cópia dos arquivos.

Agora sim uma pista. Eu não sei se entendi direito, mas talvez seja algum problema no isolamento dos privilégios do SO.

De forma educada, pergunte a ele de o porquê de ele pensar ser necessário fazer esse tipo de teste. Tente descobrir de onde ele tirou isso...

Não. Os projetos ACBrMonitor e ACBrNFeMonitor é que serão unificados no ACBrMonitorPlus.

https://github.com/mantisbt-plugins/source-integration

Desculpe acho que não fui claro. Eu quis dizer descrever os motivos das alterações, não alistar as alterações em si...

Por favor, poderia descrever suas alterações?

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]".

Esse tópico deve ter vazado na peneira quando foi criado o subfórum... Movido.

Quais foram os parâmetros que você utilizou? Essa procedure tem dois muito importantes neste caso, Documentos e Finalidade.

Acho que o André já subiu uma versão para testes: Só não sei se tem isso que foi mencionado nesse tópico.

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]".

Acho que o comando que você quer é o TACBrECF.ArquivoMFD_DLL(). Poderia verificar?

Verifique como é feito no programa de Exemplo do ACBrTEFD.

Qual a sua IDE?

Se a mudança tiver sido essa, poderia sim.

Muitos tem visto que o código dependendo do tamanho do BD do seu cliente algumas operações podem ficar muito lentas. Em especial notamos isso na geração dos arquivos como SPED e Sintegra. Então, na medida do possível, estou analisando aqui alguns métodos que são muitas vezes utilizados e podem fazer grande diferença no código para otimizá-los, fazendo-os serem executados com o mínimo de tempo possível. Especificamente neste caso, as vezes o problema está na constante alocação de memória e redimensionamento das strings. Vejam um exemplo o código do método ACBrUtil.TiraPontos. O método atual é executado várias vezes nos registros Sintegra. A seguinte linha abaixo causa realocação de memória ao redimensionar a string xStr toda vez que é executada: xStr := xStr + str[i] Podemos remover essa realocação por inicializar a string no começo e apenas redimensioná-la no final. Nos meus testes isso reduziu o tempo de execução em pouco mais de 80%. Quer dizer, se você utiliza esse método várias vezes chegando ao tempo total de aproximadamente 1,33 segundos, o tempo gasto depois de corrigido é de menos de 0,23 segundos. Criei o projeto abaixo para demonstrar como isso pode afetar o código quando é executado muitas vezes. Assim outros podem testar e ver a otimização. program project; {$APPTYPE CONSOLE} uses SysUtils, ACBrUtil, Diagnostics; function TiraPontosX(Str: string): string; const InvalidChars : set of char = ['/',',','-','.',')','(',',',' ']; var i, Count: Integer; begin SetLength(Result, Length(str)); Count := 0; for i := 1 to Length(str) do begin if not (str[i] in InvalidChars) then begin inc(Count); Result[Count] := str[i]; end; end; SetLength(Result, Count); end; var st1: TStopwatch; c: Extended; s: string; I,N: Integer; begin try { TODO -oUser -cConsole Main : Insert code here } st1 := TStopwatch.Create; for N := 1 to 3 do begin st1.Start; for I := 0 to 3000000 do begin s := ACBrUtil.TiraPontos('0.0'); end; st1.Stop; c := st1.ElapsedMilliseconds; Writeln(FloatToString(c)); st1.Reset; end; for N := 1 to 3 do begin st1.Start; for I := 0 to 3000000 do begin s := TiraPontosX('0.0'); end; st1.Stop; c := st1.ElapsedMilliseconds; Writeln(FloatToString(c)); st1.Reset; end; Readln; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. Aproveitei para adicionar alguns testes para esse método específico e não causar nenhum problema ao inserir a otimização. (: Essa não é uma mudança que resolve todos os problemas. O método precisa ser chamado muitas vezes para começarmos a ver diferenças. Mas se fizermos isso com mais funções, com certeza teremos uma execução muito mais rápida. Conseguindo fazer o mesmo com outros métodos avisarei aqui nesse tópico.

Acho que não entendi a diferença. Um arquivo .dpk é um package ou pacote. O que poderia ter mudado é o nome do pacote ou do arquivo dpk.

É porque ela precisa uma porta COM para funcionar com o ACBrECF. Essa porta COM pode ser virtual, talvez utilizando o driver da Bematech.

Olá Luiz, Como você mesmo descobriu, o problema não é na parte do FlushFileToDisk. Poderia ser se você não tivesse atualizado seu código e estivesse sendo usado o Flush do Drive inteiro. O que poderia ser então? Lógico que sem ver a máquina é difícil de dizer, mas eu começaria a olhar por coisas benignas (Antivírus, Firewall, AntiMalware, aplicativos de proteção bancária, aplicativos de aceleração que varrem os arquivos mais utilizados) e vírus e Malwares... Falando sobre antivírus, eu me lembro de ter tido um problema parecido em um cliente. O detalhe era que mesmo desabilitando o Antivírus, ele ainda continuava varrendo os arquivos. Não bastava marcar o Antivírus para ficar inativo por um tempo. Nós tivemos que colocar o executável, o banco de dados, os arquivos temporários do TEF e o arquivo AAC na lista de arquivos confiáveis dele. Finalmente, resolvemos trocar de antivírus e resolveu... Só que já não me lembro qual foi o antivírus...

Na verdade, seria melhor você dizer qual foi o erro "bobo". Isso poderia ajudar a outros que passarem pelo mesmo problema.

Mas o Fortes Report mudou o modo de instalação para o quê?

Tópico duplicado?