EMBarbosa

É provável que isso signifique uma das duas situações abaixo: Algum arquivo do ACBr está sendo alterado depois de ter sido compilado; Algum pacote (ou seu projeto) está encontrando arquivos compilados com versões diferentes dos arquivos fontes; Verificar os path tanto do Delphi como do seu projeto e a enviroment variable "PATH" do Windows podem ajudar.

Mesmo assim, muito obrigado pela intenção e pelo retorno Sandro. Bom trabalho por aí!

Esse problema não é novo. Na verdade o padrão para componentes é manter o NeverBuid marcado depois que foi lançado. Tem mais informações na documentação. http://docwiki.embarcadero.com/RADStudio/Rio/en/E2225_Never-build_package_'%s'_must_be_recompiled_(Delphi)

Habilite e verifique os logs do TEF. Talvez encontre alguma informação que se repita nos momentos de travamentos. Perguntas a avaliar: Ocorre em todos as transações TEF desse usuário? Existe alguma peculiaridade nas transações que travam? (Ex.: é uma transação com desconto? Com mais de um pagamento? Com mais de um cartão? etc...) Será que não está havendo bloqueio do teclado e mouse em horário incorreto e isso está sendo percebido como travamento? Será que a rede VPN não está instável durante a transação? Talvez caindo e retornando deixando o aplicativo perdido? E no visualizador de eventos do Windows? Tem alguma informação relacionada a sua aplicação, ao Sitef ou a rede? Eu começaria por aí...

Verifique o seguinte link se há algum anexo antigo que você pode apagar: https://www.projetoacbr.com.br/forum/attachments/

Olá Murilo. Esse ajuste foi por causa do seguinte tópico: Depois de vê-lo, talvez você possa detalhar melhor que tipo de problema está encontrando.

Qualquer erro deste tipo é bug do compilador ou da IDE. Como o nome diz é um "erro interno". É muito difícil saber o que levantou o problema porque mesmo que o erro seja levantado em uma linha, ele pode estar relacionado a um código de outra unit ou dcu. Tente verificar o que o BigWings mencionou acima. Caso não encontre nada, sugiro: Instalar o IDE FixPack (se ainda não tiver feito) Verificar se há patches pra sua versão do Delphi que não foram instalados tentar com outra versão do Delphi fazer um update to revision do ACBr para a versão que funcionava e ir manualmente fazendo update to revision até encontrar o ponto que gera o problema

Vocês conseguem reproduzir o travamento?

Depende do que os seus clientes estão reclamando. Sugiro você pegar uma reclamação concreta (talvez a que a maioria faz) e fazer buscas pra resolver ela primeiro. Gosto muito das perguntas mais populares no site UX (parente do StackOverflow): https://ux.stackexchange.com/questions?tab=Votes De modo geral, isso está relacionado a experiência do usuário, usabilidade de aplicação, interface de usuário, UIX (user interface expirience)... Coisas similares podem ter resultados em pesquisas.

Nesse caso deve ser a versão mais atual. O que limita então a ter que procurar o que realmente está causando o "Out of memory". Talvez uma fragmentação da memória. Mas daí já complica...

Você usa o FastMM? Se sim, qual versão?

Talvez sejam os componentes Core Lab MyDAC... Não sei se ainda existem em algum lugar...

Erro 500 geralmente é erro no Servidor. O indicado é contatar o responsável pelo servidor para pedir mais informações sobre o erro. Por outro lado, talvez a requisição esteja malformada. Nesse caso, você precisa verificar a requisição que está enviando e analisar se ela realmente está do jeito que a documentação do servidor precisa receber.

Quantos itens são? Qual a versão do seu Delphi? Testou com o aplicativo de exemplo?

Algum antivírus, ou aplicativo de segurança bancária na máquina? Isso explicaria o travamento. Outra possibilidade é a aplicação ser multithreading e estar havendo Deadlocks ou conflitos de lock.

Você provavelmente está com os fontes incorretos. O evento está programado sim.

Depois de avaliar a questão das margens conforme o José Júnior mencionou acima, tente ver esse post:

Os pacotes estão sendo separados em DesignTime e Runtime. Isso significa que agora temos dois pacotes para quase todos os componentes. Como a separação do pacote MDFe ainda não foi pro SVN, ele ainda precisa do pacote Designtime do ACBr_Comum, ou seja, precisa do DCLACBr_Comum.

Eles devem ter mudado de ideia ou se equivocado na versão 3.0.2. Mas muito obrigado pelas contribuições. Se encontrar mais algum problema, fique a vontade pra nos avisar. Bom trabalho por aí!

Que ótimo que deu certo! Muito obrigado pelo retorno também. Bom trabalho por aí!

Apenas para informação: Se alguém quiser fazer essa alteração no código fonte ficaremos gratos e felizes em analisar a contribuição. Nesse caso, queira criar um novo tópico e anexar os arquivos alterados por favor.

Boa tarde. Não sei se notou, mas o arquivo que você citou está desatualizado uns 6 anos. É melhor você contatar a certificadora (Software Express, SkyTef, ou outra), para poder ter a versão mais atual dos manuais.

Muito obrigado pela contribuição, @Lazaro Pavao e @Leandro Araújo Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 19552. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 19551. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Boa tarde. Muito obrigado pela contribuição. Fiz a implementação baseada nela. Mas não subi a alteração do nome do campo no registro C185. Não encontrei essa alteração no Guia Prático versão 3.0.3. Subi as demais alterações para o SVN na Revisão 19550. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.