Daniel Simoes

Consulte o manual do ECF, nem todos os ECFs conseguem retornar todas informações nesse comando...

Acredito que seus fontes do ACBr estão desatualizados... Eu uso o Lazarus 1.1 (Win) em produção no meu dia a dia...

Seu ECF é USB, se sim provavelmente esse é o problema, pois quando vc desliga o ECF a porta serial morre... Somente o estudo do LOG gerado pelo ACBrECF pode dizer o problema

Se você já está usando portas seriais, provavelmente o ECF está em uma velocidade diferente...

Não faremos a geração desse XML... não se preocupe muito com isso, provavelmente essa função só será utilizada pelo utilitário do fabricante do SAT

Apliquei novo Update do Invision para o Forum na versão 3.4.4.

Isso está relacionado a TEF ? (pois você postou na área do ACBrTEFD) use a busca do fórum e procure por "pouco papel"

O fato de ser Sweda ou Bematech não tem efeito para o ACBrTEFD... Tudo que ele faze é disparar o evento em que você deve programar a impressão das vias... (analise o conteudo que o componente envia no LOG gerado pelo componente... ou então observe como é feito no TEFDDemo

Como você pode imprimir algo se não fechar o cupom antes ?? porém se o Cheque equivale ao total da venda então a venda realmente deve ser fechada... e na sequencia impresso o TEF

Precisaram mudar muita coisa ? Eu acreditava que era só declarar -dNOGUI nas opções de compilação...

Olá para todos, Hoje fiz um grande commit no SVN, modificando todas as chamadas a diretivas de {$IFDEF CONSOLE} para {$IFDEF NOGUI}. O motivo é que conforme me explicaram na lista oficial do Lazarus, a compilação em Linux sempre traz a diretiva CONSOLE ligada, mesmo em uma aplicação Grafica (GUI).. Portanto, as verificações da diretiva CONSOLE do Linux poderiam causar problemas de compilação.. Também enviei modificações efetuadas pelo colega Luiz Camara, da lista de email "Lazarus Brazil" para que a compilação em Lazarus possa conviver pacificamente com outros projetos que também usam a Synapse e OpenSLL.... Isso pode requere um "Clean Up + Build All" na sua IDE do Lazarus... Espero não ter "quebrado" nenhum código, testei em Lazarus e Delphi e aparentemente está tudo OK... Se alguem notar algo errado (principalmente o pessoal do ACBrFramework), é só me avisar.. ficarei atento...

Pode ser a velocidade... esse modelo vem configurado por default em 115.200 bauds... Verifique com a empresa do software se há como modificar a velocidade de Baud raute nas configurações do programa... Outra possibilidade (mais difícil) é modificar o ECF para valocidade 38.400, que era usada anteriormente...

A DLL da Daruma muda a velocidade do ECF para 115.200... você deve fazer o mesmo no ACBrECF.Device.Baud Porque a DLL muda a velocidade sem avisar ninguém só o fabricante pode esclarecer..

Compilar uma nova versão provavelmente não resolveria o problema... Qual é a exata msg de erro na instalação ?

Parece ser um bug no create do componente... Ele está tentando atribuir o Texto antes de atribuir o tipo.... A solução e simples, atribua o texto em Run Time

Primeiro tenha certeza de que o .SO da Daruma está corretamente instalado... Use o Demo deles, para Linux (acho que tem um em QT) e tente gerar o arquivo com o Demo deles... Se necessário, solicite ajuda do suporte deles, para configurar o .SO

Realmente só o fabricantes do ECF poderia dar mais detalhes sobre o ocorrido... Isso é feito pelo Sw.Básico do ECF, e não pelo componente...

Não deu pra compreender o problema corretamente... está muito confuso... A configuração do PINPAD é feita no arquivo CliSiTEF.ini que deve ficar na mesma pasta da DLL que está sendo chamada

Não deu pra compreender qual o problema enfrentado... Mas observe que nesse teste você estará quebrando o sincronismo dos arquivos, e o G.P. não se comportará de forma usual.... O melhor nesse caso, é solicitar mais orientações aos homologadores... ligue na Sw.Express..

Você se refere ao arquivo anexado ? Se SIM, qual a exata mensagem de erro ?

O componente atualmente está usando a carga da DLL de forma Estática... (veja a unit ACBrSATEmuladorSPstatic.pas) Isso faz qualquer binário que use o componente depender imediatamente da SAT.DLL (mesmo a IDE do Delphi ou Lazarus) Isso é provisório, até compreendermos uma forma de usar a carga dinâmica com sucesso (sem erros de A.V.), conforme já está implementado em: ACBrSATEmuladorSP.pas

O ACBrETQ apenas usa o sensor de GAP da Impressora... Ou seja, é a impressora que decide qual o pulo... A bobina de etiquetas e o ribon estão posicionados de forma correta ? Já vi casos em que o mal ajuste de um destes confundiu o sensor de gap

Não há nada que precise ser ajustado nos fontes do ACBr.. muitos usam essa rotina com sucesso... Tente você mesmo usando o Demo ECFTeste.exe Os seus problemas parecem ser relacionados ao Path e nome de arquivo escolhido... Tente o C: ou invez de D: Evite o uso do diretório Raiz, use uma subpasta Ex: C:\ARQS\ Evite o uso de nomes longos espaços ou pontos no nome dos diretórios ou arquivos

Se não me engano, pelo Terminal Service você pode mapear uma Porta Serial remota...