Jump to content
Notícias do ACBr

click.png

click.png

click.png

click.png

click.png

click.png

clube mobile


Cursos grátis para toda base ACBr
+ Promoção Clube Mobile para o ACBr Pro

Saiba mais

adriano santos

click.png

click.png

click.png

click.png

click.png

click.png

Delcio

Membros
  • Content Count

    41
  • Joined

  • Last visited

  • Days Won

    2

Delcio last won the day on November 7 2017

Delcio had the most liked content!

Community Reputation

58 Excellent

1 Follower

About Delcio

  • Rank
    Membro

Profile Information

  • Sexo
    Masculino
  • Location
    Planalto Alegre - SC

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Olá Italo, sim, já faço isso, mas algumas coisas fogem de nosso controle, por exemplo quedas na conexão durante o envio da inutilização, neste caso ao tentar inutilizar novamente trato o retorno, que vem com os dados da inutilização original e armazeno no banco. São casos raros, mas acontecem.
  2. Olá pessoal. Pequeno ajuste para permitir a leitura do protocolo e outras informações da inutilização em caso de Rejeição 682 "Já existe pedido de inutilização com a mesma faixa de inutilização"; Segue em anexo: pcteRetInutCTe.pas
  3. Percebi isso, boa parte está sendo direcionada para System.Net, mas acho ela muito "dependente" das APIs do SO, e muito fechada também, por exemplo a implementação para o windows está em System.Net.HttpClient.Win e fica toda na seção implementation da Unit, muito engessada na minha opinião. Não consigo usar o certificado carregado no ACBr com ela, e não consigo herdar para sobrescrever algo, até consigo registrar outra classe com TURLSchemes.RegisterURLClientScheme para usar com o windows por exemplo, mas tem que implementar toda ela. Minha ideia inicial com Indy seria fazer uma im
  4. Fiz mais uns testes por aqui criando uma classe http 100% Indy, tive alguma evolução, mas acho que vou ter que partir pra outra biblioteca. O Indy usa OpenSSl para a conexão segura, consegui fazer o Indy funcionar com o certificado carregado no ACBr usando OpenSSl, funcionou tanto com Certificado A3 quanto com A1 carregado em memória, mas fui barrado por outro problema: Parece que o Indy ainda não suporta as versões mais novas da OpenSSL, daí só funcionou com TLS 1.1, que não nos atende. Vou tentar outro caminho: Alterar a TDFeHttpOpenSSL para suportar certificado A3, se der cer
  5. Olá. Consegui fazer funcionar com o Context do TDFeSSL, porém teria que ver se o inicio da assinatura da classe TWinHTTPClient não mudou nas versões mais novas, tenho só o D10.3.1 aqui. Está em anexo, se quiser dar uma olhada. Talvez fosse melhor implementar uma classe HTTP do zero, baseada em Indy ou outra biblioteca mais independente da RTL, já que a TDFeHttpIndy atualmente nem usa Indy mais. Assim que conseguir um tempo vou dar uma pesquisada sobre algo nesse sentido. Em um cenário ideal ela teria que: Compilar em x68 e x64; Não depender da API do S.O,
  6. Pois é, não me atentei a esse detalhe, nos meus clientes estão todos instalados, vou verificar se tem como resolver isso.
  7. Olá pessoal. De uns tempos pra cá venho tendo alguns chamados relativos a problemas de comunicação com o TLS1.2 usando a httpWinHttp, grande maioria devido as atualizações do windows(ou a falta delas), estive buscando então alternativas para evitar esse transtorno: A httpWinINet depende de configurações do IE, que de vez em quando são alteradas por outros aplicativos e acabam causando o mesmo problema. A httpOpenSSL além de causar dependências das Dlls acho que só vai de A1 e infelizmente tem uns que insistem no A3. Um opção seria usar a HttpIndy, que não depende de config
  8. Verdade, acabei não testando o código de exemplo antes de postar e esqueci de umas coisas; O correto é esse: type TTest = class private FVar: Pointer; public constructor Create(var CheckInstanceVar); virtual; destructor Destroy; override; end; constructor TTest.Create(var CheckInstanceVar); begin inherited Create; FVar := @CheckInstanceVar; end; destructor TTest.Destroy; begin if TTest(FVar^) = Self then Pointer(FVar^) := nil; inherited; end; ... var A, B: TTest; begin A := TTest.Create(B); B:= A; A.Free; A := TTest.Create(B); // Agora
  9. Entendi sim, as duas variáveis estão apontando para o mesmo endereço, e é justamente isso que causa a confusão, no final do código as duas variáveis estão armazenando o mesmo objeto. Exatamente isso que impede eu comparar se "A" é igual a instância que eu tinha anteriormente e referenciei em "B". O que eu precisava era uma forma de saber se meu "A" é a mesma instância de antes. Não me atentei a esse detalhe de endereçamento, e isso causou o problema; Resumindo: Uma variável armazena uma referência a um endereço, e não o objeto em si.
  10. Usei esse código apenas como exemplo, no meu caso nem reaproveito a variável, mas o erro acontece de forma semelhante ao exposto, pois o endereço da memoria do objeto que foi armazenado para posterior comparação é ocupado pelo novo objeto, e quando comparo usando "=" retorna True, mesmo sendo uma nova instância, pois aponta para o mesmo endereço da instancia anterior. No meu caso a destruição/criação do objeto depende de fatores que não posso controlar, como a interação do usuário. Resolvi armazenando uma referência para comparação no próprio objeto;
  11. Os objetos são "iguais", mas não deveriam ser o "mesmo", pois são instancias diferentes. Isso causa confusão e foi motivo de um bug em nosso sistema. Também pensei em FreeAndNil, mas tem que ser em B, o problema é que não tenho acesso a B onde libero A. Veja: var A, B: TObject; begin A := TObject.Create; B := A; FreeAndNil(A); A := TObject.Create; // Agora A é outro objeto ShowMessage( BoolToStr(A = B, True) ); //True end; Preciso armazenar um determinado objeto e depois, em outro local da aplicação preciso verificar se ele continua send
  12. Não testei no FPC, mas no delphi tem também e realmente é a mesma coisa que "="; TObject tem GetHashCode, mas também retorna o mesmo valor;
  13. Olá estou quebrando a cabeça. Preciso armazenar um objeto e depois comparar se é ele mesmo. parece simples, mas tem umas pegadinhas, veja abaixo: var A, B: TObject; begin A := TObject.Create; B := A; A.Free; A := TObject.Create; // Agora A é outro objeto ShowMessage( BoolToStr(A = B, True) ); //Exibe "True" end; Como assim? Eu sei... O operador "=" apenas compara se os endereços na memória são iguais, e como variáveis são ponteiros pra endereços de memória, deve ser porque o mesmo endereço onde A estava armazenado é "aproveitado" para arma
  14. Olá pessoal. Uma sugestão que melhoraria o AcbrBoleto em ambientes Web, quando gero a remessa, preciso gerar em um arquivo temporário pra depois enviar(download) para o browser. Adicionei um método GerarRemessaStream, que gera a remessa diretamente em um TStream, eliminando a necessidade de gerar/excluir arquivos nesses casos. Grato. ACBrBoleto.pas
×
×
  • Create New...