Ir para conteúdo
  • Cadastre-se

Daniel Simoes

Fundadores
  • Total de ítens

    29.386
  • Registro em

  • Última visita

  • Days Won

    781

Tudo que Daniel Simoes postou

  1. Qual é exatamente o passo a passo para reproduzir o problema, no ECFTeste ?
  2. Poste um fragmento de código que simule o problema...
  3. Seu código não funcionará... porque Screen.ActiveForm sempre será o Form Principal (e não o Form dentro do TDI) Tente a seguinte modificação, em anexo... ControleAtual := Screen.ActiveControl; FormAtual := FindFormParent(ControleAtual); if (not Assigned(ControleAtual)) or (not Assigned(FormAtual)) then Exit; function TControledecor.FindFormParent(AControl: TControl): TCustomForm; var AParent: TControl; begin Result := Nil; if not Assigned(AControl) then Exit; AParent := AControl.Parent; while Assigned(AParent) and not Assigned(Result) do begin if (AParent is TCustomForm) then Result := TCustomForm(AParent) else AParent := AParent.Parent; end; end; ulcontroledecor.pas
  4. @André Ferreira de Moraes, favor verificar essas sugestões...
  5. Verifique a comunicação com a Balança, usando o Demo do ACBrBal
  6. Eu sinceramente não compreendi o que você pretende fazer e se deseja ou não submeter alguma sugestão de fontes para a analise... Um fato, é que não iremos modificar os fontes para UTF8... então se você realmente insistir nesse tipo de modificação eu não posso lhe ajudar... ou acatar suas contribuições... Boa sorte com o Fork
  7. Poderia anexar um mini projeto, que demonstre o problema ?
  8. Por favor descreva melhor o problema de usar CP1252 em compilação cruzada... (não compreendo como isso pode ser um problema) Em relação as Units que entrarão ou não na compilação... basta ajustar os IFDEFs... talvez alguma nova diretiva possa resolver isso... Não há nos fontes do ACBr algo como {$IFDef LINUX} (pois isso não seria compatível com a compilação em Mac)... mas há várias diretivas como {$IfDef MSWINDOWS}... provavelmente nesse cenário de Cross compiling que você descreveu, ela permaneça desligada... e com isso vc tem problemas... experimente adicionar no final do ACBr.INC algo como: {$IfDef Win32Compiler} // Troque Win32Compiler por alguma diretiva, que você tenha certeza que esteja ligado no cenário de compilação cruzada {$DEFINE MSWINDOWS} {$EndIf} Eu acho que criar um Fork apenas para isso seria um esforço desnecessário...
  9. Desculpe... mas sem um passo a passo de como reproduzir os problemas, no Demo do ACBr... não consigo lhe ajudar...
  10. Obrigado pela contribuição... Fiquei na dúvida... notei que a modificação introduziu um parâmetro novo, que pode fazer sentido apenas para o SiTef... Infelizmente estou com pouco tempo no momento, para analisar uma outra proposta... Volto a analisar novamente a questão em alguns dias...
  11. Alguns erros na sua lógica de operação... SAT.Ativar("24637177000161","35") ERRO: ACBrSAT não foi inicializado corretamente SAT.Inicializar OK: SAT inicializado SAT.Inicializar - Deve ser chamado antes de qualquer outro comando ao objeto SAT (deve ser o primeiro comando) Você não deve chamar SAT.Ativar e SAT.AssociarAssinatura a cada venda... Isso é um erro.... Você apenas deve usar esses comandos, uma única vez, em toda a vida do SAT (a não ser que o cliente troque de Sw.House ou CNPJ)
  12. E como o MonitorPLUS poderia saber se o CFe foi enviado ou não? Uma vez que não é ele mas o SAT quem faz o envio?
  13. De qual IDE você está falando ? Eu uso o ACBr com Lazarus em Linux 64 bits, a anos... O ACBr usa CP1252 para ser compatível com D7.. isso não será alterado em curto prazo... e nem é necessário... Todos as Strings acentuadas do ACBr são tratadas pelo método ACBrStr() que converterá para UTF8 ou UTF16 (conforme a IDE) Isso é proposital, pois o ACBr é multiplataforma... a Unit que você citou... ACBrDFeWinCrypt.pas, jamais compilaria no Linux (pois invoca a API do Windows) O ACBr sempre funcionou em Lazarus e Linux.. nosso aplicativo "DJPDV" usa 100% do ACBr e pode ser compilado com Lazarus no Linux 64 Se mesmo assim achar necessário... fique a vontade para fazer um Fork... desde que respeite a licença original do projeto...
  14. Veja... você definiu 48 colunas, e esse equipamento somente suporta 42 -- 07/10 11:23:05:146 - TraduzirTag(</linha_simples>) -> ------------------------------------------------
  15. Aparentemente você está ultrapassando o número máximo colunas suportado pelo equipamento
  16. O ACBrMail em si, não carrega nennhuma DLL... mas o PlugIn de segurança da Synapse, que é usado pelo componente ACBrMail, irá carregar as DLLs do OpenSSL
  17. Vc precisa usar 128-C.. mas nem todos equipamentos suportam isso...
  18. Usar a CliSiTef.dll é MUITO melhor e mais performático do que a troca de arquivos...
  19. copie as DLLs apenas na mesma pasta do seu .EXE (evite o DLL hell)
  20. Não há um código fixo que funcione para todas as impressoras... você precisa saber exatamente qual a linguagem suportada pela sua impressora
  21. Ele realmente não deve enviar email para ReplyTo... esse endereço é apenas uma instrução de qual email deve ser usado quando o destinatário responder ao email... Se você quer receber cópia do email, use CC ou BCC
  22. Verifique se você tem as DLLs do OpenSSL, na mesma pasta da sua aplicação .EXE
  23. Se você não descrever exatamente a mensagem de erro... ou como reproduzir o problema... fica impossível ajudar...
×
×
  • 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.

The popup will be closed in 10 segundos...
The popup will be closed in 10 segundos...