Daniel Simoes

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Não temos nada nesse sentido... mas com o ACBrETQ, seria possível construir...

você diz, a linguagem de página ZPL2 ? (para impressão de etiquetas ?)

Pode ser que esse modelo de Impressora não suporte BackFeed

@Nelson A Sousa, Apliquei uma possível correção, nos fontes do SVN... Commit [r19423] Como posso reproduzir o problema ? o Nome do arquivo INI é atribuído geralmente em "LIB_Inicializar"... você muda ele de alguma outra maneira ?

Creio que não... afinal estamos seguinte o mesmo padrão que sempre existiu no TList e seus descendentes...

Não compreendi... qual exatamente o Erro com a ACBrLib no Linux ? O ACBrMonitor foi projetado para rodar em Terminais de Venda, 1 para 1... não é indicado para esse cenário... Temos o componente ACBrNFSe, mas ele ainda não foi exportado para a ACBrLib ou para o ACBrMonitor... Seu uso está disponível apenas para usuários Delphi/Lazarus, através do componente nativo

É uma interpretação... mas pense... se hoje os programadores entende que o Assign é para copiar os objetos (e não duplica-los), e se nós mudamos para ele duplicar... Teremos um monte de usuários com MemoryLeak Na implementação do FPC e Delphi, de Assign para o TList, você pode escolher qual o comportamento do Assign Observe que o código padrão do Delphi/FPC de TList.Assign, é apenas Copiar a referência dos objetos da lista, e não duplica-los... procedure Assign(ListA: TList; AOperator: TListAssignOp = laCopy; ListB: TList = nil); TListAssignOp = (laCopy, laAnd, laOr, laXor, laSrcUnique, laDestUnique); ... // on with the show case AOperator of // 12345, 346 = 346 : only those in the new list laCopy: begin Clear; Capacity := LSource.Capacity; for I := 0 to LSource.Count - 1 do Add(LSource[I]); end;

Talvez seja necessário atualizar o Firmware... Entre em contato com o Fabricante Não conheço nenhuma...

Qual é o passo a passo para reproduzir o problema ?

Sua Unit está desatualizada em relação aos fontes atuais do SVN... Mas o problema não parece ser esse pois TMedCollection -> TACBrObjectList -> TObjectList -> TList e em TList existe a implementação do método "Assign"

Sim... basta carregar o XML e mandar imprimir... Veja exemplo no Demo do ACBr

mas foi justamente isso que modifiquei nos Demos... provavelmente você não atualizou o SVN, ou não testou com os mesmo Demos... Veja: https://sourceforge.net/p/acbr/code/19413/

Acho que o problema... é que a Lib salva as configurações na memória, para o Disco, sem verificar se o arquivo em Disco, recebeu modificações... Vamos pensar em uma maneira de corrigir isso..

Consegue reproduzir esse comportamento com o Demo ? Como devemos chamar inicializar a Lib, para que esse problema ocorra ?

Muito Obrigado... Assim que tiver o Modem para testes... eu analiso esse caso e o indicado no tópico...

Provavelmente você está usando uma Etiqueta que não tem o GAP, no local esperado pelo Sensor dessa Impressora...

As informações são muito vagas... Você consegue reproduzir o problema com o Demo ? Pode ser algo no seu código, uma condição de Erro/Exception, que modifique o fluxo da execução do programa, não chamando o comando de Impressão

Eu não tenho IPhone, e não tenho interesse em continuar essa analise... Mas o ACBr é OpenSource... todos podem analisar os fontes e tentar contribuir...

não tenho mais sugestões... visto que todos os demais leitores funcionam... me parece ser um bug do Leitor do Iphone...

Creio que o @Rafael Dias, irá criar... porém ele está afastado por problemas de saúde... Se desejar implementar, e anexar os fontes, podemos avaliar e subir para o SVN...

Será ótimo... agradecemos muito a ajuda...

Obrigado pela contribuição... enviei para o SVN... Commit [r19414]

Obrigado @PauloTenório, Notei que os anexos estavam como "InLine"... e não como "attachment"... ou seja.. parece ser um problema na chamada do Demo do ACBr, e não do componente... Enviei um ajuste dos Demos, para o SVN.. Commit [r19413]

Não compreendi... eu não modifiquei os comandos enviados...