Rafael Batiati

Ok, pela seu printscreen, vc definiu a porta do exemplo como COM6, e o emulador de ECF como COM5, certo? Não é necessário ter o Delphi pra rodar, a DLL é nativa e não tem dependências. Não entendi como vc quer definir a porta no ACBr? No código em java, usa-se ACBrECF ecf = new ACBrECF(); e depois ecf.setPorta("COM6"); No exemplo, o prompt pergunta a porta do ECF, basta digitar COM6 mesmo. Eu já passei por problema parecido com o emulador de porta. O comando "abre cupom" é enviado mas o emulador não responde, nem executa nem dá erro. Depois o próximo comando falha com a mensagem "comando não executado". Como eu disse, passei por isso numa máq Win7 64bits, usando o Free VirtualSerialPort; Consegui reproduzir o mesmo erro usando o ECFTeste.exe do ACBrMonitor. Com a impressora real funcionou normalmente, por isso constatei que o problema deveria ser do emulador de portas no Win7 64. Como vc está dizendo que seu windows é 32bits, não sei ao certo o que pode ser. Faz um teste com o ECFTeste.exe; basta baixar o ACBrMonitor e executar esse utilitário que está dentro da pasta do ACBrMonitor; Lá vc encontra "Testar cupom fiscal" que faz exatamente o que esse nosso exemplo faz: abre o cupom e vende alguns itens. Abs,

Oi augusto, Qual emulador de porta serial você está usando? Eu tive um problema parecido com esse, usando o emulador Free VirtualSerialPort, em máq 64bits. Mas com a impressora real rodou sem problema. abs,

Oi José Augusto, Seja bem vindo. Bom saber que contamos com mais um usuário do projeto. Por enquanto não temos a DLL compilada em 64bits; Para compilar em 64 bits, não seria (pelo menos teoricamente) um esforço maior que mudar o target do compilador do Lazarus para x64. Mas não fizemos isso ainda pois não tivemos oportunidade de testar e debugar em ambientes x64. Está também em nossos planos compilar para Linux ... Por enquanto, em Java, você poderá indicar a JRE 32bits para executar o aplicativo, e a DLL 32bits será carregada normalmente. Qualquer dúvida, fique a vontade. Abs,

Pessoal, há dois problemas básicos aí: 1. O projeto ACBrECFDLL.dll não é a mesma coisa que o ACBr32.dll. O ACBr32.dll fica em "Projetos\ACBr32_DLL" e o ACBrDLL em "Projetos\ACBrDLL" Assim como o ACBr32.dll, este outro projeto é também uma tentativa de exportar o componente ECF do ACBr para uma DLL, mas feito de forma diferente do ACBr32.dll; Alguma coisa é semelhante, mas não há compatibilidade nem suporte pelo ACBr32.dll 2. O projeto ACBr32.dll foi feito para o uso em QUALQUER linguagem de programação. Inclusive em Delphi. Em Delphi, concordamos que o natural é utilizar os componentes ACBr, mas não há impedimentos em utilizar a ACBr32.dll. Neste caso, não temos um exemplo feito em Delphi, o programador pode basear-se nos exemplos feitos em C ou em FoxPro que utiliza a DLL diretamente, basta seguir as declarações da DLL no código em Delphi. O problema nesse caso, não é que não exista a função para desativar a impressora, você só não declarou as funções em seu código Delphi, por isso não funciona. *** Com o aumento da audiência do ACBr32.dll, eu estou escrevendo um artigo sobre o trabalho desenvolvido até agora, e acredito que será útil para quem quiser contribuir com o desenvolvimento deste projeto, e talvez mais útil ainda para quem quiser entender o porquê das "doideiras" desse projeto. Abs,

Alô Daniel, Vi que você tem uma dúvida quanto ao uso do ACBr32.dll utilizando Delphi. O problema aí, não é que a DLL não funcione com o Delphi, mas sim que com o Delphi, o uso dos componentes nativos é a melhor saída. Sugiro que você tente resolver o problema da instalação dos componentes e passe a usá-los. Para usar a DLL diretamente em Delphi, seria necessário seguir algum exemplo feito em C ou em FoxPro que utiliza a DLL diretamente. Não temos a intenção de suportar o uso direto em Delphi. Caso tenha alguma dúvida, fique a vontade. Abs,

Alô, A DLL no momento suporta os métodos/Propriedades do ACBrECF. As declarações das funções contidas no acbr32dll.prg na pasta de exemplo são antigas e alguma coisa nova já deve ter aparecido. Você pode pegar a DLL mais nova na pasta Projetos\ACBr32_DLL\ACBr32\ e ver a lista de funções detalhadas no arquivo ACBrECFDll.pas, lá no fim na seção "exports" todos os métodos que estão implementados. Se você for alterar as declarações no acbr32dll.prg, eu agradeço muito se puder manda-lo de volta para que possamos manter os exemplos sempre atualizados. Qualquer dúvida quanto às assinaturas e funcionamento das funções, fique a vontade para perguntar. Abs,

Oi, Eu recompilei a DLL do JNI com a runtime do C++ estática, dessa forma não vai mais depender de instalação na máquina. Acho que a DLL que você estava usando foi compilada com a runtime do C++ 2005, e eu te passei o 2008 pra instalar, enfim ... Baixe a última versão, e veja se funciona. Abs!

Alô rpassos. Fiz uma atualização na DLL do JNI que corrige esse bug; De uma forma muito "traiçoeira", o JRE enviava uma string UTF para o ACBr. Ao comparar = "D" ou = "A" isso falhava pois o caracter UTF é de 2bytes. Na runtime do .NET, o UTF de 2 bytes é preenchido com zero no byte não usado e passado assim pro Delphi; mas na runtime do Java não sei ainda porque isso não aconteceu. Pra descobrir terei que debugar o lado Java, o lado JNI e o lado Delphi. Vou revisar se existem outros flags desse tipo no sistema pra tratar da mesma forma, e avaliar se outras strings sofrem algum problema. Pode baixar a última versão e testar. Abs.

Opa, isso é causado pelo ACBr32_JNI sim. Só pra esclarecer, o .Net framework não tem influência nesse caso, o jACBr depende apenas da interface JNI e do JVM; Aí é que pode estar o problema: 1. A máquina instalada com o CD do XP pode não ter a runtime do C++ que foi utilizada pra compilar o ACBr32_JNI; Baixe ela aqui, e instale na máquina: http://www.microsoft.com/download/en/details.aspx?id=29 2. O JVM instalado pode não ser compatível com a versão utilizada pra compilar o JNI; Ele foi compilado com o 1.6; Abs!

A limitação quanto ao USB é dos componentes ACBr; O mesmo protocolo do ECF serve tanto para USB quanto para Serial, mas no caso das USBs cada fabricante utiliza um hardware diferente que exigiria o uso de um driver específico para enviar os bytes até o equipamento. A forma elegante de resolver isso sem onerar o projeto, é utilizando o driver do próprio ECF que emula uma porta serial. Dessa forma, o driver faz o serviço específico da USB, cabendo ao ACBr enviar o protocolo como se fosse uma Serial. Acredito que a maioria dos ECFs possuam esse driver USB capaz de criar a porta serial virtual, nesse caso o pessoal mais experiente no ACBr poderá nos ajudar na resposta. ******* Quanto à velocidade da impressora, sim, a versão do jACBr que você está utilizando não suporta ainda definir a velocidade. Isso já foi implementado há alguns meses atrás no ACBr32.DLL e no ACBr.NET, mas por descuido meu, não fiz no jACBr. Vou aproveitar então para evoluir o jACBr com as mesmas funções do ACBr.Net Qualquer dúvida, fique a vontade. Abs,

Alô rpassos, antes de mais nada fico feliz em saber que está usando o jACBr. Vou reproduzir o seu caso para ver onde está o problema, pode ser no JNI ou no código do jACBr mesmo. Fique a vontade para postar dúvidas, problemas, sugestões, etc ... Abs,

Obrigado Regys, Quer dizer que dependendo da propriedade que eu chame essa classe será populada com dados diferentes. Entendido. abs,

Oi Rodrigo, Eu implementei as propriedades que existiam no componente ACBrECF. Até conferi novamente, mas a DadosUltimaReducaoZClass não existe, só a DadosReducaoZClass. Não sei o porquê de não existir essa propriedade, vamos precisar da ajuda da turma do ACBr pra responder a essa questão. Alguém sabe? Abs!

Pessoal, novas mudanças no projeto: 1. Implementado a propriedade DadosReducaoZClass, que retorna as informações de forma estruturada dentro de uma classe. Note que o resultado só vem corretamente preenchido depois que a função DadosReducaoZ é chamada. Ou seja, chame primeiro a propriedade DadosReducaoZ com retorno String pra depois chamar a DadosReducaoZClass, é um comportamento do ACBr. 2. Corrigido as propriedades DadosReducaoZ e DadosUltimaReducaoZ, que retornavam o texto cortado. Atualizem o código via SVN. Comentários, dúvidas, sugestões, pedidos, reclamações e OffTopics são muito bem vindos! Abs

Fala Rodrigo, As propriedades DadosReducaoZ e DadosUltimaReducaoZ estão agora com um buffer de tamanho maior. Não é necessário alterar a função GetString, pois ela possui um argumento extra que é exatamente o tamanho do buffer, pra ser usado nesses casos. A alteração ocorreu diretamente nas propriedades da class ACBrECF. Está implementado também a propriedade DadosReducaoZClass, que retorna as informações de forma estruturada dentro de uma classe. Note que o resultado só vem corretamente preenchido depois que a função DadosReducaoZ é chamada. Ou seja, chame primeiro a propriedade DadosReducaoZ com retorno String pra depois chamar a DadosReducaoZClass, é um comportamento do ACBr. Atualize seu código pelo SVN, Qualquer coisa, estamos aí. Abs,

Opa, é verdade, precisamos aumentar o tamanho máximo do retorno nesses casos. Está pendente também a propriedade da mesma família DadosReducaoZ que retorna um objeto com os valores, ao invés da string. Vou alterar isso. Abs!

Parabéns pessoal! Uma grande conquista pelo reconhecimento. Na verdade, a Embarcadero tem motivos de sobra pra se orgulhar em ter um projeto de tão alto nível e uma comunidade tão atuante. Abs!

Rodrigo, os métodos estão implementados, veja em: viewtopic.php?f=19&t=5078 Baixe o código do SVN. Abs,

Pessoal, há uma solução pra isso: viewtopic.php?f=19&t=5078 Baixem o código do SVN. Abs,

Pessoal, o método IdentificaPAF foi implementado. viewtopic.php?f=19&t=5078 Baixem o código do SVN. Abs,

Pessoal, Há uma nova versão do projeto no SVN, confiram: 1. Método IdentifacaoPAF implementado; viewtopic.php?f=19&t=4987 2. Propriedades DadosDaUltimaReducaoZ e DadosReducaoZ implementados; viewtopic.php?f=19&t=2664&start=20#p23990 3. Corrigido acentuação e caracteres especiais. viewtopic.php?f=19&t=3782 4. Corrigido o Dispose() dos componentes viewtopic.php?f=19&t=4847 O erro só acontece quando o VisualStudio executa em Debug. Para solucionar, vá na propriedade do projeto executável, na aba Debug, marque "Enable unmanaged code debugging" *** Pra quem estiver interessado em ajudar no desenvolvimento do projeto, eu estou elaborando um pequeno documento com dicas para entender como as coisas funcionam nesse mundo de interoperabilidade entre Delphi e .Net; Entendendo isso, o restante é moleza. O projeto ACBr32.DLL foi compilado em Lazarus. O projeto ACBr.Net foi compilado no VisualStudio 2010 Express Comentários, dúvidas, sugestões, pedidos, reclamações e OffTopics são muito bem vindos! Abs

Eu concordo. Acho que o principal a fazer é definir primeiro o que queremos implementar, vamos criar uma lista de coisas a fazer. Depois, com o projeto baixado na máquina, vamos dividindo as tarefas. O código .NET e o código Delphi estão muito fáceis de trabalhar, não acredito que tenhamos dificuldades nisso. Qualquer dúvida sobre o funcionamento e design do projeto, estou a inteira disposição. Abs,

Tranquilo!! Eu também não estava me queixando de nada, muito pelo contrário ... Estou mesmo é pedindo desculpas por não ter dado a atenção que o projeto merece. Sei que é muito arriscado para um desenvolvedor utilizar um componente em seu projeto sem que tenha um desenvolvimento ativo e uma comunidade participativa. Mas vamos reverter esse quadro, e tentar chegar o ACBr32.DLL e ACBr.NET no mesmo nível que qualidade e participação do ACBr. Abs!

Opa pessoal, boa noite. O ACBr.DLL e ACBr.Net não estão parados não! De fato tem havido pouca ou quase nenhuma atividade ... Como eu já havia dito antes, eu iniciei o ACBr.NET com tudo que foi necessário para homologação do meu AC para o TEF Dedicado (SiTef). Após isso, o plano era dar continuidade na evolução dos componentes para a homologação no PAF. Infelizmente minhas prioridades inverteram-se e fui inserido em outros projetos; mas inevitavelmente a homologação no PAF ocorrerá, e sem dúvidas utilizando o ACBr.Net Durante todo esse tempo de inatividade do projeto, eu continuei ativo no fórum, justamente para detectar novas necessidades e novos usuários no projeto. Essa é a verdadeira matéria prima de um projeto OpenSource: usuários. Agora parece que as coisas estão esquentando, e não tenham dúvida, toda ajuda será bem vinda. Estarei disponível para implementar ou auxiliar na implementação dos componentes tanto na ACBr.DLL, quando na ACBr.NET ou até nos outros projetos iniciados como jACBr e ACBrActiveX. ******* Voltando agora à pergunta original: O método IdentificaPAF não está implementado na ACBr32.DLL nem no ACBr.NET; Na verdade, não implementei nenhum método que eu não sabia ao certo onde usar no PAF. Estou fazendo um TODO dos métodos de fácil implementação que poderá dar um gás aos novos usuários, e assim que puder estarei fazendo checkin disso no SVN. Fiquem à vontade para apontar tudo que estiver faltando! Grande abraço

Alôs! O ACBr e o ACBr.NET implementam nativamente os protocolos dos ECFs suportados; assim as dlls dos fabricantes não vão juntas do ACBr. As mensagens no XML da Daruma, por exemplo: DarumaFramework - Mensagem Não Programada DarumaFramework - Mensagem Não Programada Você poderá passá-las como parâmetro para os métodos do AcbrECF SubtotalizaCupom ou para o FechaCupom Abs,