Ir para conteúdo
  • Cadastre-se

Daniel Simoes

Fundadores
  • Total de ítens

    27.046
  • Registro em

  • Última visita

  • Days Won

    758

Tudo que Daniel Simoes postou

  1. Eu não compreendi a requisição... o DANFCe do ACBr em Fortes, Fast e EscPos, já fazem a impressão do Logotipo lateral
  2. Isso depende ds versão ABECS instalada no PinPad... A mais atual, e que trm mais recursos é a 2.12 Somente o fabricante consegue atualizar a versão da ABECS, em seu ambiente seguro.. Tente com o Demo do ACBrAbecsPinPad
  3. Links dos manuais Online ACBrLib: https://acbr.sourceforge.io/ACBrLib/ACBrLib.html ACBrMonitor: https://acbr.sourceforge.io/ACBrMonitor/ACBrMonitor.html
  4. Obrigado pela análise detalhada e contribuição...
  5. O componente ACBrNFe roda em Android... por favor tente rodar o Demo do ACBrNFe.. AnsiString é redeclarado em ACBrBase.pas, mas os fontes do ACBr já tratam disso... Eu creio que seja algum problema nas configurações do Projeto... Por favor tente rodar o Demo do ACBrNFeAndroid
  6. Mas de qualquer forma não faria sentido 2 Packages carregarem uma mesma Unit... Os pacotes de Design Time precisariam ser revistos
  7. @DeveloperATS, No Seu Log, o retorno parece ser: Essa informação é EndToEnd que vocês precisam ? Todas os campos retornados pelo SiTef, são mapeados para propriedades internas, em ACBrTEFCliSiTefComum.pas, veja o método: procedure ConteudoToPropertyCliSiTef(AACBrTEFResp: TACBrTEFResp); dessa Unit... O registrador 4249, ainda não é mapeado... você pode acessar diretamente o Log capturado pelo ACBr, usando o índice do campo.. veja um exemplo: RespostasPendentes[i].LeInformacao(4249,0).AsString;
  8. Olá @Mega Online, Poderia por favor , anexar o Log que você gerou ?
  9. Notei que os Demos, precisariam de ajustes, para enviar a Resposta com '-1' ou '-2', conforme os botões pressionados... Alguém pode por favor subir as Units dos Demos alteradas?
  10. Creio que seja aqui: http://svn.code.sf.net/p/acbr/code/branches/ACBrBombas/
  11. Enviada a contribuição do @joão vitor de fraga venancio... Commit [r33017]
  12. Recebi uma informação sobre o código de Erros do Warsaw CÓDIGO DE RETORNO: -1; SIGNIFICADO: Existe alguma falha ao carregar a DLL do warsaw; AÇÃO: Verificar as dependências instaladas na máquina (necessário VCRedist 2013). Caso o erro persista, instalar o certificado da Amazon na máquina do cliente Esse instalador, instala todas as dependências do VCRedist: https://github.com/abbodi1406/vcredist/releases
  13. olá @LeonardoRocha, infelizmente não temos nada nesse sentido...
  14. @Victor H. Gonzales - Panda, parece ser falta de uma chamada a ParseTXT, correto ?
  15. Parece haver mudanças nos Demos, do seu lado... Pode ser que o Delphi tenha sugerido a remoção do evento, por achar incompatível algo, em sua IDE (Ex: String vs AnsiString) Experimente por favor apagar os demos, e baixar novamente pelo SVN
  16. Vamos continuar em:
  17. por favor continue no tópico indicado acima..
  18. São pacotes de Design Time... que tem as instruções para o Object Inspector @EMBarbosa, tem alguma opinião a respeito ?
  19. @Italo Giurizzato Junior e @Diego Foliene Analisando essa questão, notei que o problema ocorre nas Units que ainda usam o antigo PCN... A antiga versão da rotina "ParseTXT" tinha uma característica (bug), de sempre retornar um ANSI, mesmo quando o parâmetro de entrada, era um UTF8... Isso causava problemas, quando precisávamos gravar os XMLs em UTF8, ou carregar ele na LibXML2 Após a correção da ParseTXT, todos os métodos que chamam ela, precisam ser revisados O Delphi espera que os caracteres que ele irá manipular em Tela, estejam em ANSI (no windows) e UTF8 no Android e Linux... Então é necessário, tratar isso, antes de mover para as propriedades dos objetos... Exemplo de ajuste em ACBrCTeWebServices.pas, linha 1113 FCTeRetornoSincrono.Leitor.Arquivo := UTF8ToNativeString(ParseText(AXML)); FCTeRetornoSincrono.LerXml; O Problema não ocorre, nas classes que usam TACBrXmlDocument, como Reader, pois essa classe que faz uso da LibXML2, já espera os dados em UTF8
  20. Desculpe pela demora na resposta... Faz muito tempo, que implementamos o componente MTER, e o Demo dele... Lembro que algumas coisas ocorriam de forma Assincrona.. então Sleeps não são uma boa técnica... Notei no Demo que tem o Evento: procedure TForm1.ACBrMTer1RecebeDados(const IP: AnsiString; const Recebido: AnsiString; var EchoMode: TACBrMTerEchoMode); que acaba chamando o método: procedure AvaliarRespostaTerminal(aIP: String; const aResposta: String); Repare que ele tem estados que só pintam uma msg e saem, e que ele fica aguardando um "Enter", para buscar um Item, caso contrário, apenas adiciona o caractere digitado, no Buffer anterior if (aString[1] <> #13) then begin // Grava Resposta Edit; FieldByName('RESPOSTA').AsString := FieldByName('RESPOSTA').AsString + aString; Post; Exit; end;
  21. @paulorsa, Isso quebra os eventos implementados com a assinatura anterior, correto ?
  22. @DatawebDev, acho que teríamos colisão de pacotes veja... - Você sugere a inclusão de ACBrTEFAndroid.pas em ACBr_TEFD.dpk - mas essa Unit já será carregada por DCLACBr_TEFD.dpk, pelo Uses de ACBrTEFDReg.pas
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.