Jump to content

EMBarbosa

Consultores
  • Content Count

    7,228
  • Joined

  • Last visited

  • Days Won

    84

EMBarbosa last won the day on August 6

EMBarbosa had the most liked content!

Community Reputation

2,407 Excellent

About EMBarbosa

  • Rank
    Moderador

Profile Information

  • Sexo
    Masculino
  • Localização
    MG

Recent Profile Visitors

6,307 profile views
  1. https://stackoverflow.com/questions/3627743/delphi-thread-exception-mechanism
  2. Bom dia. Os próximos códigos que você colar, por favor, cole em modo texto. Isso facilita. Tem uma opção pra colar código no editor do post... Voltando... Na verdade eu não perguntei sobre travamento da tela, eu me referi ao comentário que você fez anteriormente sobre a variável teste: Como assim o travamento é na variável? Você precisa ter essa verificação no execute, especialmente quando faz um loop "While True". Se a aplicação estiver sendo terminada, quem vai avisar a thread que ela pode parar de trabalhar? Caso isso não aconteça ela vai continuar executando, passando a impressão que a aplicação está travada. Bom, se a aplicação está travada, ela não terminou. Se ela não terminou, não tem como verificar se houve memory leak... Então não podemos afirmar nada, mas cuidado com isso... Eu não posso dizer que compreendi bem a sua arquitetura aqui... mas você não deve acessar valores globais dentro do método Execute da thread. Se vai acessar qualquer valor fora da thread precisa no mínimo do método Synchronize (para acessar a thread principal) e em outros casos, Semáforos ou Mutex... Não faça isso. Em threads, você precisa fazer um tratamento especial pra exceptions... Dá uma olhada no Google. E se a aplicação estiver sendo terminada, como fica? E onde está o tratamento de sincronização entre as duas threads? Não é isso o que o código da chamada está mostrando. Você está passando um objeto já criado para o método Create da Thread... Então ele não faz parte da Thread. É importante entender que a VCL não é inerentemente "thread safe". Então você precisa codificar para evitar locks e race conditions. Nesse caso, acho melhor você procurar alguma coisa já pronta, ou pelo menos parcialmente pronta. Use o VNC por exemplo. Desenvolver um acesso remoto não é tão fácil quanto parece...
  3. Com esse novo cenário que você passou fica um pouco difícil de analisar sem mais informações. Por exemplo, o que você quer dizer com "o travamento é exatamente nela"? Você não verifica o Terminate no Execute da thread. Está ciente que isso está faltando? Quantas vezes a thread é criada? Ela é liberada da memória? Onde foi definido essa variável Lista e idProprio? O que faz o método Existe? E o método SetObjDesktop? Por que tem um Try..Except em branco? Como a thread sai do loop while True se o Socket estiver conectado? A propósito onde são definidos esses sockets?
  4. Você não pode acessar variáveis fora do contexto da Thread sem o método Synchronize. Então: Em primeiro lugar, você não pode acessar o Form1 no método TTeste.Create. Em segundo lugar, você não pode acessar a variável Terminou dentro do Execute fora do Synnchronize().
  5. Olá, Me parece que está faltando o arquivo dfm ou lfm alterado.
  6. Para que funcione A4 você deve utilizar o componente TACBrNFeDANFCeFortesA4. Acho que o programa exemplo não tem o componente que acabei de mencionar acima.
  7. Existem a propriedade ACBrTEFD.ArqLOG e a propriedade ACBrTEFD.TEFCliSiTef.ArqLOG. Sempre que trabalho com eles, eu preencho de forma a apontar para arquivos diferentes. Não acho que seja problema no sistema do TEF. Geralmente é um problema no fluxo mesmo... Sua pergunta me fez querer olhar o código novamente. Então, dei uma olhada no código fonte do componente aqui e encontrei essa mensagem de erro. Ela é levantada quando a propriedade AguardandoResposta é True e você faz uma nova requisição (CRT, ADM, ATV, CHQ, etc...). Você pode observar que o log que você anexou parece estar preso em um loop, que parece o loop do método TACBRTEFDCliSiTef.ContinuarRequisicao (arquivo ACBrTEFDCliSiTef.pas). Estaria assim sempre repetindo o comando 23, que no caso executa o evento OnAguardarResp. Então o TEF parece estar aguardando o pinpad, mas daí você inicia o processo novamente antes de terminar. Verifique esse evento e como o seu sistema poderia ficar preso nesse loop. Por exemplo, será que o sistema encarou que já acabou o Tef só porque teve problemas na leitura do cartão (Cartao com Erro ou Mal Inserido)?
  8. Já percebeu que você e sua equipe de desenvolvimento estão passando boa parte do tempo procurando e corrigindo erros? Realmente é impossível se livrar do trabalho de depuração (debugging) de um software... O que pode ser feito para reduzir o tempo e ser mais eficiente? Elton Barbosa, Consultor e parte da equipe de desenvolvimento do projeto ACBr, com grande experiência em equipes pequenas e eficientes vai apresentar uma palestra que pode ajudar a ser mais eficiente nessa parte do desenvolvimento que é fundamental para um sistema bem sucedido. A palestra é voltada para usuários do Delphi, mas os princípios são úteis em todas as linguagens de programação. Inscreva-se para o Dia do ACBr 2019 e assista a essa e outras palestras voltadas pra você. Se tem dúvidas ou gostaria mais informações, fale com nossa consultora rapidamente por meio do WhatsApp.
  9. Como foi dito antes pelo BigWings, o firebird 3.0 não é amarrado a internet. Você pode ver nesse link que apesar das mudanças, ele continua aceitando o acesso local ou pelo Loopback (que é o mesmo que local mas simulando o acesso pela rede). Você consegue fazer um ping no 127.0.0.1 na sua máquina? você consegue acessar seu banco usando um aplicativo de terceiros? Por exemplo FlameRobin ou IBExpert?
  10. Esse erro específico é porque foi introduzida nas versões mais recentes do Delphi as "unit scope names". Agora a unit Graphics não existe mais, sendo substituída por VCL.Graphics ou pela FMX.Graphics. Então é preciso tratar isso...
  11. Infelizmente, esse arquivo fr3 não funciona com essa versão porque faz uso dos scripts... Veja esse post em que explico essa diferença:
  12. Esse é o log do CliSiTef. Poderia anexar o log do ACBrTEFD também? A mensagem de erro parece indicar que você está tentando iniciar uma nova requisição antes de terminar a anterior (concluindo ou cancelando). Você verificou isso? Você consegue reproduzir esse problema utilizando o programa de exemplo do ACBrTEFD?
  13. Eu sugiro desabilitar o "Error Insight". Infelizmente esse é um recurso do Delphi que não funciona muito bem. Esse é o caminho: Menu Tools -> Options -> Editor Options -> Code Insight -> Source file type: escolha "Pascal" -> Error insight (desmarque a opção) Veja a imagem: O problema desse recurso (Error Insight) é que ele trabalha de forma independente do compilador. Então nem tudo que o compilador consegue "compreender", essa ferramenta entende... Parece que há uma previsão no roadmap para a versão 10.4 em que isso vai ser corrigido. Mas até lá, assim que instalo o Delphi eu desabilito essa opção. Recomendo a todos a fazerem o mesmo.
  14. Olá cefantacini, Que bom que conseguiu resolver. Obrigado por dar um retorno dizendo o que era. Isso com certeza vai ajudar outros no futuro. Vou te responder essa pergunta, mas por favor, da próxima vez crie um novo tópico para um assunto novo. Temos uma regra no fórum sobre isso. O objetivo é organizar o fórum e facilitar a localização das informações a longo prazo. Por favor, queira reler o tópico sobre as regras, em especial a regra 2.2: Agradecemos sua compreensão. Agora vamos ao seu novo problema... No código, vai depender de como você está lendo os seus arquivos. Um jeito mais fácil é converter os arquivos de uma vez usando alguma ferramenta. O Lazarus tem uma ferramenta para converter todos os arquivos do projeto. Veja ela no menu "Ferramentas -> Converter a codificação dos arquivos do projeto..." Caso prefira uma abordagem arquivo por arquivo, a maior parte dos editores de texto, incluindo o Notepad++ pode fazer isso pra você.
×
×
  • Create New...