Delcio

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;

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 sendo o mesmo, não se é igual, mas se é a mesma instancia anterior. Já contornei o problema original, mas não achei a solução ideal, deveria haver algo como TObject.SameInstance, já que o operador "=" só verifica se o ponteiro das duas variáveis é o mesmo, e sim ele é o mesmo, mas os objetos não, já que o primeiro foi destruído e e criado novamente. Mas eu intendi, o operador é de igual, e não de "mesmo": Dois carros iguais não significa que são o mesmo carro. Mas achei interessante deixar este problema exposto para que outros não caiam nesta "arapuca". Resolvi mais ou menos assim: 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 inherited; if FVar = Self then FVar := nil; end; ... var A, B, C: TTest; begin A := TTest.Create(B); A.Free; A := TTest.Create(C); // Agora A é outro objeto ShowMessage( // BoolToStr(A = B, True) // ); end;

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;

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 armazenar o novo objeto. Mais uns testes: var A, B, C: TObject; begin A := TObject.Create; B := A; A.Free; C := TObject.Create; //C é outro objeto ShowMessage( BoolToStr(A = C, True) ); //Exibe "True" ShowMessage( BoolToStr(Pointer(A) = Pointer(C), True) ); //Exibe "True" ShowMessage( BoolToStr(A.Equals(C), True) ); //Exibe "True" end; Mas e agora? Usei variáveis diferentes(A e C), continua sendo o mesmo endereço. O objeto C é criado no mesmo endereço onde estava armazenado A. Os objetos são iguais, mas não são a mesma instância. Preciso saber se é a mesma instância. Tem alguma maneira sem ter que dar um B:=nil, visto que onde destruo A não tenho acesso a B, e se possível sem ter que alterar a classe original, adicionando uma referencia ou algo do tipo.

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

Pelo que percebi é isso mesmo. estou com bastante trabalho nesses dias, assim que tiver um tempinho vou ver se consigo testar melhor e levantar mais informações. Não chega a ser um problema grave, só incomoda um pouquinho as vezes.

Testei em dois pcs diferentes, ambos em resolução de 2560x1080, no Firefox o consumo é menor, mas também ocorre. Quanto a GPU dedicada não tenho, talvez possa ser, mas acho que tenha mais a ver com a execução de alguns timers dentro dos scripts, pois se interrompo eles pelo debug do browser o processamento cai. Mas não impede a navegação. No PC local ocorre o mesmo sintoma mas nem é perceptível, apenas acessando pelo Terminal que as vezes fica lento, quando a Thread da página está no mesmo núcleo que o Terminal Services.

Sem título.mp4 Bom Dia Pessoal. Percebi um pequeno detalhe ao acessar tópicos do fórum ACBR, principalmente em monitores com resolução mais alta: Consumo alto de processamento, nem chega a ser tão alto assim e talvez passe despercebido a quase todos da comunidade, mas como trabalho por RDP, o acesso fica muito lento quando o browser e o terminal services dividem o mesmo núcleo do processador. Pelo que percebi ocorre devido a timers executando repetidamente tarefas em alguns scripts. Um abraço a todos.

Olá. O Município de Planalto Alegre mudou de provedor, de Betha para IPM. Se alguém puder fazer a alteração no SVN agradeço. [4213153] Nome=Planalto Alegre UF=SC Provedor=IPM

Olá Pessoal. Percebi que que as propriedades ValorPago e ValorRecebido não estão implementadas da mesma forma para todos os bancos na leitura do retorno. No momento estou trabalhando com Sicredi, Bancoob e BB, e estão assim: Bancoob: ValorPago = Valor que o cliente pagou; ValorRecebido = Valor creditado na conta; Sicredi: ValorPago não está sendo lido; ValorRecebido = Valor que o cliente pagou; BancoDoBrasil: ValorPago não está sendo lido; ValorRecebido= Valor que o cliente pagou; No meu entendimento o mais correto seria o Bancoob; Seguem em anexo as Units do Bancoob e BancoDoBrasil com as alterações sugeridas e os devidos manuais. ACBrBancoSicredi-15550.pas Sicredi manual-cnab-240_2017.1.pdf CbrVer04BB.pdf ACBrBancoBrasil-15550.pas

Verdade, meu ambiente de desenvolvimento é bem personalizado, como por exemplo versão do FastReport que não é a padrão, não tenho versões antigas e nem Lazarus instalados para testar. Vou ter que montar uma VM para essa finalidade, gostaria de colaborar mais com o projeto, mas no momento a coisa tá bastante corrida por aqui. Espero poder mexer nisso em breve. Vou deixar aí caso alguém consiga se aventurar na empreitada.

Precisava implementar Notas Promissórias em meu sistema e resolvi criar um componente para tal, segue mais ou menos o padrão do ACBrBoleto, caso seja útil e alguém queira incorporar ao projeto. Feito: Criadas as Classes; Criado o Relatório em Fast Report; Criado um Demo Básico(em implementação); Falta: Testar e melhorar; Compatibilizar com Lazarus; Criar relatórios em outras plataformas; Para testar: extrair o anexo dentro de trunk2, adicionar as pastas ao Library do Delphi e instalar os .pkg; trunk2.zip Exemplo de uso: var NovaPromissoria: TACBrPromissItem; I : Integer; begin ACBrPromissoria1.ListadePromiss.Clear; with ACBrPromissoria1 do begin // Favorecido with Favorecido do begin Nome := 'Fulano Que Vai Receber'; CPFCNPJ := '41811877000140'; end; // Praça de Pagamento with PracaPagamento do begin Logradouro := 'Rua Do Pagamento'; NumeroRes := '171'; Complemento := ''; Bairro := 'Centro'; Cidade := 'Planalto Alegre'; UF := 'SC' end; // adiciona promissoria with CriarPromissNaLista do begin Numero := '01/2018'; DataEmissao := Now; DataVencimento := IncMonth(Now, 1); Valor := 100.35; // devedor with Devedor do begin Nome := 'Fulano Que Deve'; CNPJCPF := '79766710066'; Logradouro := 'Rua do Devedor'; Numero := '111'; Complemento := ''; Bairro := 'Centro'; Cidade := 'Planalto Alegre'; UF := 'SC'; end; // Avalista with Avalista do begin Nome := 'Fulano Avalista'; CNPJCPF := '79766710066'; Logradouro := 'Rua do Avalista'; Numero := '222'; Complemento := ''; Bairro := 'Centro'; Cidade := 'Planalto Alegre'; UF := 'SC'; end; end; end; for I := 2 to 5 do begin // outra maneira de adicionar promissorias NovaPromissoria := ACBrPromissoria1.CriarPromissNaLista; NovaPromissoria.Numero := IntToStr(I) + '/2018'; NovaPromissoria.DataEmissao := Now; NovaPromissoria.DataVencimento := IncMonth(Now, I); NovaPromissoria.Valor := 100.35; // devedor NovaPromissoria.Devedor.Nome := 'Fulano Que Deve'; NovaPromissoria.Devedor.CNPJCPF := '79766710066'; NovaPromissoria.Devedor.Logradouro := 'Rua do Devedor'; NovaPromissoria.Devedor.Numero := '111'; NovaPromissoria.Devedor.Complemento := ''; NovaPromissoria.Devedor.Bairro := 'Centro'; NovaPromissoria.Devedor.Cidade := 'Planalto Alegre'; NovaPromissoria.Devedor.UF := 'SC'; // Avalista NovaPromissoria.Avalista.Nome := 'Fulano Avalista'; NovaPromissoria.Avalista.CNPJCPF := '79766710066'; NovaPromissoria.Avalista.Logradouro := 'Rua do Avalista'; NovaPromissoria.Avalista.Numero := '222'; NovaPromissoria.Avalista.Complemento := ''; NovaPromissoria.Avalista.Bairro := 'Centro'; NovaPromissoria.Avalista.Cidade := 'Planalto Alegre'; NovaPromissoria.Avalista.UF := 'SC'; end; Resulta em:

Essa unit está incompleta, pois não tive tempo de terminá-la, porém o pessoal do ACBR reescreveu e concluiu ela, recomendo que atualize os fontes e use a seguinte configuração: XMLSignLib = xsLibXml2; Fiz muitos testes e não consegui simular a exclusão do certificado com essa configuração, inclusive estou usando assim algum tempo sem mais problemas. Mais informações em:

Olá amigos. Ao homologar os boletos junto ao BB foi me retornado o seguintes problemas: > Header de Arquivo < Lote 0000 > -------------------------------------------------------------------- Posições 164 a 166: Campo Não tratado. Preencher preferencialmente com brancos ou zeros, seu arquivo informou: [030] > Header de Lote < Lote 0001 > -------------------------------------------------------------------- Posições 014 a 016: Campo Não tratado. Preencher preferencialmente com brancos ou zeros, seu arquivo informou: [020] Verifiquei que nos fontes esses valores estavam fixos, alterei para permitir usar os valores setados no componente Linha 339 >> PadLeft(IntToStr(fpLayoutVersaoArquivo), 3, '0') linha 358 >> PadLeft(IntToStr(fpLayoutVersaoLote), 3, '0') e deixei no constructor os valores anteriores para manter a compatibilidade com quem já usava com os valores fixos. Linha 123 >> fpLayoutVersaoArquivo:= 30; fpLayoutVersaoLote:= 20; Segue em anexo a unit caso alguém queira verificar e subir. ACBrBancoBrasil.pas

Se você usa certificado A3 a unica forma de evitar a perda de mais certificados é usar a nova biblioteca de assinatura que não depende da libxml5.dll que causava esse problema. Já testei amplamente e não ocorreu mais a exclusão usando as novas classes, inclusive estou usando em produção já. Mais informações em:

Testei aqui (na NFe somente) e funcionou bem, ficou bem mais limpa.

Humm, olhei só para TDFeSSLXmlSignClass e não analisei a TDFeSSLCryptClass, fiz um retrabalho danado pois o método CalcHash já assina o Hash também . Apenas fiquei na duvida no seguinte: Seguindo esse principio que você passou, na TDFeSSLXmlSignMsCrypto quem de fato geraria o Hash e a assinatura seria a TDFeWinCrypt, enquanto nas outras a isso fica a cargo da própria classe, como no caso da TDFeSSLXmlSignXmlSec, da TDFeSSLXmlSignMsXml e da TDFeSSLXmlSignMsXmlCapicom, isso não chega a ser um problema, mas não fica meio fora do padrão?

Segue uma prévia da Unit. Antes de mais nada: USE POR SUA CONTA E RISCO. NÃO ME RESPONSABILIZO POR QUALQUER PROBLEMA QUE POSSA DECORRER DESSE CÓDIGO DIRETA OU INDIRETAMENTE! (sim é gritado mesmo). Não está pronta, precisa implementar/melhorar/testar muita coisa ainda, se você não é um desenvolvedor do ACBR é melhor esperar um versão final. Está funcionando: Assinatura de NFe; Assinatura de Evento da NFe; Assinatura de Inutilização de Numeração da NFe; Validações de DFe; Precisa ser feito: Implementar VerificarAssinatura; Testar com certificado CNG(no momento não tenho nenhum em mãos, mas vou ter que resolver isso pois pretendo colocar em produção em breve); Melhorar a forma de seleção dos elementos a serem assinados; Compatibilizar com outros documentos(no momento tenho apenas NFe em produção no ACBR); Testar/Compatibilizar com Lazarus; Verificar Memory Leaks; Alterações nas demais Units para suportar a nova classe; Estou com pouco tempo disponível então toda ajuda é bem vinda. Qualquer dúvida estou a disposição. ACBrDFeXsMsCrypto.pas

Sim, já segui esse padrão, ela vai depender apenas da libXML2, que usei para aplicar as transformações. Estou terminando de fazer os ajustes, depois posto a unit para ser avaliada.

Boas Novas: Consegui assinar usando a MScrypto sem MSXML e LibXMLSec. Amanhã vou refatorar e testar se não causa nenhum problema no certificado.

@Daniel Simoes é fogo, agora resolveram enviar e-mail. E ainda por cima a explicação deles não tem nada a ver com oque realmente acontece. Não consegui fazer essa dupla funcionar, então parti pra assinatura direta, usando somente a MSCrypto, gerando o hash, assinando e aplicando as transformações diretamente no XMl, não é um processo tão complicado, mas estou apanhado pra aplicar a Canonification c14n, não estou conseguindo selecionar corretamente os nodes para aplicar o cn14, o resto estaria pronto já.

Sim estava testando com senhas diferentes e sempre é solicitado o PIN. Fiz mais alguns testes: Testando com outro cartão, esse da Oberthur, que permite ativar um log dos acessos ao certificado descobri mais umas coisas: Após cada transação, o hardware do cartão é reiniciado como pode ser visto abaixo; 2017-11-03 16:03:10.240 (TID=9840) DEBUG [PCSCReader.cpp:83] SCardEstablishContext (0000) 2017-11-03 16:03:10.260 (TID=9840) DEBUG [PCSCReader.cpp:430] begin Transaction 2017-11-03 16:03:10.266 (TID=9840) DEBUG [PCSCReader.cpp:94] POWER_ON 2017-11-03 16:03:10.585 (TID=9840) DEBUG [PCSCReader.cpp:107] SCardConnect on reader ACS CCID USB Reader 0 (0000) 2017-11-03 16:03:10.595 (TID=9840) DEBUG [PCSCReader.cpp:629] APDU 00 A4 04 0C 10 A0 00 00 00 77 01 08 00 07 00 00 FE 00 00 01 00 2017-11-03 16:03:10.665 (TID=9840) DEBUG [PCSCReader.cpp:677] Return :90 00 2017-11-03 16:03:10.665 (TID=9840) DEBUG [PCSCReader.cpp:629] APDU 00 A4 04 0C 0D E8 28 BD 08 0F F2 50 4F 54 20 41 57 50 2017-11-03 16:03:10.695 (TID=9840) DEBUG [PCSCReader.cpp:677] Return :90 00 2017-11-03 16:03:10.695 (TID=9840) DEBUG [PCSCReader.cpp:520] end Transaction 2017-11-03 16:03:10.698 (TID=9840) DEBUG [PCSCReader.cpp:239] POWER_OFF 2017-11-03 16:03:10.702 (TID=9840) DEBUG [PCSCReader.cpp:260] SCardDisconnect (0000) Demora um tempo para essa "reinicialização" acontecer, e caso seja chamado o método createKeyFromCSP ou createKeyFromCertContext da MSXML5.dll durante esse intervalo, algum bug nessa DLL faz com que uma chamada para exclusão do conjunto de chaves seja feita ao hardware do cartão, como pode ser visto mais abaixo: 2017-11-03 16:03:10.702 (TID=9840) DEBUG [PCSCReader.cpp:260] SCardDisconnect (0000) 2017-11-03 16:03:10.704 (TID=9840) [OcsCsp.cpp:245] CPAcquireContext returned ERROR 0x80090016 2017-11-03 16:03:10.708 (TID=9840) [OcsCsp.cpp:166] AcquireContext (container "{2E6C5A0A-2AE2-7ff6-D224-EA19FB355731}", flags CRYPT_DELETEKEYSET 0x00000010) Nesse momento o gerenciador do cartão solicita o PIN e caso o usuário digite o certificado é excluído. Essa DLL é a que usamos para a assinatura dos XMLs, ela é da Microsoft, faz parte do office e na sua versão mais atual, a MSXML6 não tem mais suporte a assinatura de XMLs, portanto é muito provável que não haverá qualquer correção ou suporte nessa DLL por parte da Microsoft. Notei que a Oberthur já contornou o problema: Na nova versão 5.1.8 SR1 do AWP Manager é exibida uma mensagem de "Acesso Negado" no momento da tentativa de exclusão e o certificado não é excluído. Testei o gerenciador da Safesign e mesmo na versão mais atual o certificado foi excluído, inclusive certificados armazenados em tokens USB. Estou trabalhando em uma Unit de assinatura que usa somente a MSCRYPTO, assim que terminar vou disponibilizar aqui, precisarei de ajuda para testá-la e quem sabe assim se livramos da MSXML5 e conseguimos conviver em paz com os A3.

Acho que não resolveria, porque o usuário não está removendo o cartão, mas no momento da assinatura, quando é solicitado o PIN, o certificado dá uma "reiniciada", como se tivesse sido removido e inserido novamente. Só notei isso em métodos de assinatura que usam MSXML. Quanto ao certificado ser excluído pela biblioteca não encontrei nenhuma especificação que mencione isso, sempre diz que o certificado deve ser bloqueado em caso de tentativas de PIN incorretas, e não excluído. Então acho que os fabricantes tem alguma culpa aí sim. Também recomendo o A1 a todo custo, mas convencer o cliente a usar é outra história. Sempre tem alguém que vai dizer pra ele: Uso a anos e nunca vi isso acontecer. As próprias certificadoras recomendam o A3 e dizem que não vai ter problema, depois que a bomba explode tiram o corpo fora e colocam a culpa em nossos sistemas. Vou fazer uns testes com libXMLSec pra ver se consigo algo com ela.

Até aí tudo bem, em nenhum momento culpo o ACBR, mas entre ele o o Certificado temos vários suspeitos: MSXML, Software Gerenciador do Certificado, Hardware da Leitora e o próprio Hardware do SmartCard. O fato é que o problema, mesmo que externo ao ACBR, está ocorrendo e causando muitos transtornos as empresas. Se encontrarmos o ponto exato onde o problema ocorre, talvez possamos contornar esse problema externo pelo próprio ACBR ou mesmo forçar as Certificadoras e fabricantes de dispositivos a resolver o problema.

Mais alguns testes: Ambos os métodos "IXMLDigitalSignature.createKeyFromCertContext()" e "IXMLDigitalSignature.createKeyFromCSP()" usados nas classes TDFeSSLXmlSignMsXml e TDFeSSLXmlSignMsXmlCapicom, causaram a exclusão do certificado quando forçada a sua chamada antes do cartão estar "Operacional". Isso aumenta minhas desconfianças sobre a MSXML. Ainda não deu tempo de testar com TDFeSSLXmlSignXmlSec, libxmlSec e OpenSSL.