wrmedeiros

Obrigado @Isaque Pinheiro ! Espero que essa alteração não traga problemas para usuários de outras linguagens (clipper, etc.). Acredito que alguns trazem o conteúdo do campo por completo (string), e depois tentam converter para data por exemplo... caso façam isso, terão problemas... De qualquer forma, no layout oficial o campo de recebimento é data/hora.

Ele mesmo @Juliomar Marchetti ! Na verdade no repositório só encontrei um (Projetos\ACBrMonitorPlus\Lazarus). Eu pensava que a diferença entre o Plus e o "normal" era que o Plus era compilado diariamente pela equipe do SAC (disponibilizava o ".exe"), e o "normal" o usuário tinha que compilar.

Senhores, O recibo da NFC-e/NF-e/etc. é um campo datetime, no entanto no ACBrMonitor está sendo retornado como date. DoACBrNFeUnit.pas Linha: 3561 INIRec.WriteString('procNFe','dhRecbto' ,DateToStr(procNFe.dhRecbto)); Alteramos no nosso código para DateTimeToStr e resolveu nosso problema (a hora do recebimento da NFC-e é uma informação muito importante). Novo código: INIRec.WriteString('procNFe','dhRecbto' ,DateTimeToStr(procNFe.dhRecbto)); Alguém poderia disponibilizar essa alteração no repositório? A unit completa está em anexo. DoACBrNFeUnit.pas

Entendi @Daniel Simoes ! Realmente o TEF tem muitos eventos (na nossa versão do sistema para Windows temos o TEF implementado desde 2004)... seria complicado tratar isso pelo monitor. Ontem a Software Express me enviou a documentação/bibliotecas/exemplos em Java. Começar a brincar por aqui. Obrigado amigo.

Senhores, O ACBrMonitor funciona com vários tipos de leitores de códigos de barras, ECF's, NFe/NFC-e, etc., existe algum projeto de incluir o TEF no mesmo? Sei que existe o ACBrTEFD (Delphi/Lazarus), mas para quem utiliza outras linguagens e usa o ACBrMonitor essa possibilidade de usar o TEF via ACBrMonitor seria bastante interessante.

Bom dia Alexandre. Fiz várias buscas, e descobri que trata-se de um bug no FPC pra Linux. Abri um tópico no grupo de Lazarus, e após vários testes descobrimos que as funções só conseguem ser exportadas no Linux quando a declaração export fica dentro do lpr (arquivo de projeto). Se colocar o export da função em um .pas, não exporta. Fiz um projeto de exemplo, coloquei o export dentro do pas, não funcionou. Em seguida movi o export para o lpr, funcionou, segue exemplo: https://github.com/welkson/TesteFPC O problema é que peguei o projeto do ACBr, selecionei uma unit para testar (se não me engano ACBrECF_DLL), removi o export da unit, joguei no .lpr, gerei o .so, e após testar com readelf o problema persiste (não exporta a função). Essa semana está um pouco corrida, e não tive tempo de continuar os testes, mas minha intenção é comentar no lpr a importação de todas as uses do ACBr, em seguida habilitar apenas 1, e tentar trabalhar nas funções pra ver qual o motivo das mesmas não estarem sendo exportadas. Qualquer ajuda será bem vinda. Abraço,

Fiz um demo [1], testei pelo Windows (via Dependency Walker), funcionou perfeitamente (a função "Teste" aparece na lista de symbols). No Linux, usando o mesmo código, mesma versão do FPC + Lazarus, não funciona (via "nm", "readelf" ou "objdump", a função Teste não é exibida). Da forma como está hoje, o ACBrFramework não funciona no Linux. Estou lendo sobre exportação de símbolos no FPC, mas se alguém souber algo que possa ajudar, agradeço.

Fiz o teste na 1.4.2, mesmo problema.

Abri meu Lazarus no Windows e no Linux, conferi cada configuração do projeto, tudo igual. Verificando a versão, percebi que no Windows estou usando Lazarus 1.4.2, e no Linux 1.4.0 (o FPC é o mesmo nos 2 sistemas). Acredito que se a versão do FPC fosse diferente, poderia influenciar... mas o Lazarus provavelmente não. Na dúvida, estou desinstalando o Lazarus, e vou tentar instalar o 1.4.2. Quando concluir os testes posto os resultados.

Olá Rafael, Eu já havia feito esse teste, não exporta a função (até porque, mesmo no Windows o projeto também usa CDECL). Fiz a pergunta no fórum do Lazarus, mas também não obtive resposta. Será que o pessoal está usando o jACBrFramework apenas no Windows?

Boa noite Mauro. Como disse no post anterior, consegui gerar nas 2 plataformas, no entanto, só no Windows funciona... no Linux o .so não tem as funções (o Lazarus por algum motivo não exporta). Estou tratando isso nesse post:

Eu acredito que o erro no Java está correto, realmente não existe essa função ECF_Create no .so. Gerei a DLL on Windows, usei o Dependence Walker [1] para debugar, e o mesmo mostra todas as funções (ou seja, foram exportadas corretamente). No Linux, usando a mesma revisão, sistema x86, gero o .so, listo as funções usando "nm", objdump, readelf, e em nenhum desses aparece as funções (ou seja, por algum motivo no Linux elas não estão sendo exportadas). Vejam os screenshots no anexo. As diretivas de compilação do projeto no Linux estão no "default" (ou seja, o padrão que o ACBr usa). O que estou fazendo errado? [1] http://www.dependencywalker.com/

No Windows, usando os mesmos repositórios, fiz testes gerando a biblioteca x86 (JDK x86 também), funcionou. Tem algum procedimento diferente para gerar o .so no Linux?

Mesmo problema informado nesse tópico: http://www.projetoacbr.com.br/forum/topic/13955-dúvidas/#comment-84962

No fórum não tem quase nada sobre essa lib... Por exemplo, preparei uma VM com Ubuntu x64, instalei Lazarus, Java, etc. tudo x64... consegui gerar o .so, fui testar no Java, e nunca funcionava (erro no método ECF_Create), depois de muito teste, achei em um tópico alguém comentado que x64 não funcionava. Tentei gerar o .so com x86, mas o FPC não suportava... como era um ambiente de testes, reinstalei todo o sistema operacional com x86, gerei o .so, testei no Java, mesmo erro (ECF_Create)... fiz um svn up no no framework, tinha algumas mudanças, tentei compilar pelo Lazarus uma nova .so, e o projeto reclamou de algumas libs novas do ACBr em Pascal... fiz o svn up no pascal, nada novo... pensei, eles devem está usando trunk2, baixei o trunk2, quando fui compilar está tudo quebrado no projeto do Lazarus (corrigi alguns path's como ACBrEAD, mas já apareceu muitos outros, etc.)... em resumo, acredito que estejam usando o "trunk" (antigo) em vez do trunk2. Fiz o seguinte: Repositório JACBrFramework: atualizado (commit dia 03/08/2015 - inclusão do LFD) Repositório: ACBr (última revisão do "trunk" - como falei, aparentemente o projeto Lazarus não está preparado para trunk2) Quando tentei gerar o .so, ele reclamou que não encontrava o *LFD.pas, como não vou usar agora, e estou apenas testando, comentei a importação da unit e o .so foi gerado corretamente (CDECL x86). Copieo a lib para /usr/lib, tentei usar o demo do jACBrFramework para Java, e obtive esse erro: Exception in thread "main" java.lang.UnsatisfiedLinkError: Error looking up function 'ECF_Create': /usr/lib/libACBrFramework32.so: undefined symbol: ECF_Create at com.sun.jna.Function.<init>(Function.java:179) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:391) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:371) at com.sun.jna.Library$Handler.invoke(Library.java:205) at com.sun.jna.Native$4.invoke(Native.java:857) at com.sun.proxy.$Proxy0.ECF_Create(Unknown Source) at jACBrFramework.serial.ecf.ACBrECF.onInitialize(ACBrECF.java:2832) at jACBrFramework.ACBrClass.<init>(ACBrClass.java:9) at jACBrFramework.serial.ecf.ACBrECF.<init>(ACBrECF.java:69) at jACBrFramework.Test.Program.main(Program.java:54) Java Result: 1 BUILD SUCCESSFUL (total time: 8 seconds)

Boa tarde Mauro. Vendo o changelog percebi que o pessoal migrou de JNI para JNA, então não é mais necessário usar o C pra gerar os wrappers. Baixei o código pelo SVN, fiz os testes pelo Windows e pelo Linux, consegui gerar a biblioteca sem erros (.dll / .so). Obrigado.

Boa noite Mauro Eu conheço o projeto (jposbr), mas como você comentou, o projeto ainda está engatinhando. Minha intenção é também usá-lo e contribuir na medida do possível, mas o coordenador do projeto gostou da ideia de aproveitar o código do Delphi/Lazarus no Java (jACBrFramework), e temos uma certa urgência em terminar esse projeto. Já fizemos diversos testes (balanças, impressoras fiscais, leitores de códigos de barras, tef, etc.), mas gostaríamos de entender melhor o processo de gerar a DLL/SO, criar a interface no C (wrapper), usar no Java, etc. Pra piorar, devido esse problema no repositório do SF estou sem acesso ao código que gera a DLL, wrapper em C, etc. O Rafael Batiati ainda está a frente desse projeto?

Pessoal, boa noite! Já uso ACBr com Delphi a alguns anos, contribuo com códigos, SAC, etc., e agora estou iniciando os estudos com jACBrFramework. Gostaria de entender melhor o processo de gerar a DLL/SO do wrapper. Em alguns tópicos vi o pessoal falando sobre gerar o wrapper em C, mas não mostra mais detalhes. Estudando o módulo de TEF, observei que o código em Delphi tem alguns métodos novos, e o wrapper está desatualizado, no entanto não sei como proceder para incluir esses novos métodos e gerar a nova versão da DLL/SO. Alguém poderia passar um pequeno resumo? Os progressos que forem feitos no framework me comprometo em enviar de volta para o projeto.

Obrigado Edson. Você tem usado o JFramework em produção? Uso ACBr com Delphi a muitos anos (contribuo com código, etc.) mas iniciei os testes com Java a pouco tempo (nosso ERP é Java, mas o PDV é Delphi) e não encontro muitos exemplos.

Legal Daniel, excelente iniciativa. Dei uma olhada no código, tem bastante coisa implementada. Além do trabalho de mapear as funções do código pascal (wrapper) para usar no Java, teria algum outro motivo pra não usar o código já existente? Tem alguém usando o wrapper em produção?

Boa tarde. Estou iniciando testes com o PDV em Java. Tem alguém usando JACBrFramework em produção? recomenda? Consegui gerar o ".jar" do JACBrFramework, já associei ao meu projeto, e consegui conectar a ECF ao meu aplicativo, gerar X, etc, no entanto estou com algumas dificuldades na integração com balança (Interop), pois não encontrei exemplos, documentação ou qualquer post sobre o assunto. No projeto tem um arquivo .java com exemplos, no entanto é somente para o ACBrECF.

Edson, boa tarde. O post é meio antigo, mas você conseguiu resolver? Poderia postar um exemplo de como fez? No exemplo do JACBrFramework só mostra como utilizar ECF.

Obrigado Daniel. Como você implementou o Gertec 44 USB, vou fazer testes com ele.

Bom dia Daniel. Desculpe-me pela demora para responder. Esqueci de marcar a opção para "acompanhar o tópico"; O ACBrDis envia textos para o display do teclado?

Bom dia senhores. No nosso sistema tem suporte a teclado reduzido (Gertec, Fourth, etc.), mas a implementação está bem antiga (VXD, DLLs que só funcionam no XP, etc.), e estava pensando em migrar para ACBrDIS. Pelo que vi no código (ACBrDIS.pas), o componente suporta Gertec (PS e SERIAL), Keytec (aparentemente só PS). Alguém está usando esse componente em produção? funciona corretamente? (envia textos para o display do teclado?) Qual modelo de teclado reduzido vocês recomendam para usar com ACBrDIS?