Rafael Batiati

Excelente então. Baixe o código fonte pelo SVN (http://acbrframework.sourceforge.net/downloads/codigo-fonte/), e prepare seu ambiente, vai precisar do Visual Studio com C++ (pode ser o express), e se você tiver algum conhecimento em C# será bom para se basear em algumas soluções que já tivemos no .Net. Você já tem alguma familiaridade com o desenvolvimento em C/C++, e com JNI ? Se sim será excelente, mas nada que não possa aprender com um pouco de pesquisa, é muito simples. A primeira coisa a fazer é entender como funciona esse mecanismo, e identificar as funções que você precisa no ACBrFramework e implementá-las no JNI. Depois, como o outro post ilustra, é só fazer a "casca" em java, com as chamadas "native". Dá uma estudada, e posta as dúvidas aí pra gente. Qualquer fonte modificado pode atachar aqui no post também. Abs

Sim, no projeto ACBrFramework em Delphi, já existem as funções da DLL expostas para manipular os parâmetros da serial, basta implementar o JNI (C++) dela e depois as chamadas nativas em Java. Nosso objetivo é manter o jACBrFramework com uma API o mais parecido o possível com os componentes ACBr escritos em Delphi. Dessa forma nós podemos aproveitar do fórum os exemplos, soluções de dúvidas e formas de uso. Pra fazer isso, precisamos analisar como é o componente original no Delphi e escrever a classe Interop em JNI e Java para ele. Todas as operações que manipulam a porta serial são tratadas pela classe Device (no Delphi), que contém Porta, Bauds, Paridade, StopBits, etc, etc. No .Net nós implementamos essa classe "Device" com as mesmas capacidades e características, tal como no Delphi ela permite trabalhar com qualquer outro componente que use a Serial, como o ECF, a Balança, Leitor de código de barras, etc. A nossa idéia é implementar em Java seguindo o mesmo design. Aquele post que eu te passei antes contém alguma discussão sobre a implementação no JNI (projeto em C++) e no Java; Coisas indispensáveis no nosso caso. Caso você tenha interesse em desenvolver, posso ajudá-lo nisso. Abs,

@vtbraun Por favor, dê uma lida do tópico abaixo, lá já discutimos algo sobre o JNI. (...) Nós recomendamos que antes de fazer qualquer alteração no ACBrFramework ou no jACBrFramework, traga aqui para o fórum sua necessidade e idéias, para que possamos discutir juntos a melhor solução e integrá-las ao SVN do projeto. O jACBrFramework tem muito o que evoluir, atualmente não temos nem 50% do ECF implementado em java, enquanto no projeto ACBrFramework.Net em C# já tem dezenas de componentes completamente implementados e funcionais, entre o ECF, AAC, EAD, PAF, RFD, Sped, Sintegra, Balança, LCB, IBGE, Validador, etc. A evolução do projeto só depende da união dos esforços dos usuários e colaboradores interessados. Estamos a disposição. Abs!

Bos noite Marcos, Temos um tópico exatamente sobre isso "" Por favor, continue por lá, e evite postar antes de pesquisar, assim mantemos os tópicos mais organizados e fáceis de consultar. Abs!

Ok, que bom, a JRE parece estar ok agora. Vamos ao outro problema. Pelo que parece você está usando a jACBr, uma versão ***muito antiga*** do nosso projeto, que agora se chama jACBrFramework. O JNI é muito temperamental com essas coisas, pois se sua ACBrECF está no package jACBr ele procura o método jACBr_ACBrECF_create pra executar. Mas em nossa nova versão, o package foi renomeado para jACBrFramework, e consequentemente no JNI existe agora um método também chamado jACBrFramework_ACBrECF_create. Ou seja, ou você usa o jACBr com a ACBr32.dll e a ACBr_JNI.dll ou você migra para o jACBrFramework e usa a ACBrFramework32.dll e o ACBrFramework_JNI.dll. Pelo que eu vi no seu projeto, você está usando as DLLs novas e o jar antigo. Abs

Oi, Não sei ao certo, não uso o NetBeans, mas a JRE alí é a correta, só não sei se ele está usando essa só como classpath ou se pra executar o aplicativo também. Dá uma googlada sobre usar no NetBeans JRE 32bits em máquinas 64, vai que tem algum macete... (...) Compilar em 64 não tem mistério não, vc só precisa compilar o ACBrFramework em Lazarus usando o projeto ACBrFramework64.lpr e compilar o projeto do jACBrFramework_JNI em 64 bits também. Ele é feito em Visual C++. Mas como o Rafael Dias falou, na prática não é recomendado, pois pra fazer a leitura da MFD é necessária as DLLs dos equipamentos que nem sempre são distribuídas em 64bits. Abs

Pessoal, Foi finalizado no ACBrFramework.Net o projeto ACBrSpedTeste, 100% cópia do aplicativo de exemplo original em Delphi, nele é possível testar a geração do arquivo. Baixem o fonte e confiram. Abs.

...\ACBrFramework32.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform Isso significa que você ainda está executando no JRE de 64 bits. Nesse caso não basta apenas instalar a JRE 32bits, você precisa na sua IDE (NetBeans, Eclipse ou outro) informar o JRE de 32bits que você quer usar. Trocando em miúdos, você precisa usar o javac e java.exe do JRE correto, pois um aplicativo de 64bits não consegue carregar módulos de 32bits. Abs

Bom dia Wagner! Você simplesmente desativou o Interop, aí o erro parou de acontecer, assim como todo o resto parou de funcionar também !!! O ACBrFramework é uma DLL nativa, e funciona via JNI com o java. o this.create() que "é coisa de Delphi", na verdade é uma função nativa implementada em C++ chamada via JNI private native void create() throws ACBrException; Essa função, de fato é coisa de Delphi, pois é nela que o componente é criado e os handlers atribuídos. (...) eu acho que o seu problema pode estar no System.loadLibrary("ACBrFramework64"); Você precisa estar usando uma JRE de 64bits e usando a DLL compilada em 64bits pra isso funcionar. Aí vc precisa ver se sua DLL nativa e o JNI foi compilado corretamente. Não distribuímos versões compiladas do JNI em 64bits, só em 32bits mesmo. O mais fácil é vc manter o ACBrFramework32 e executar com uma JRE de 32bits. Abs!

Alô galera, O NFe não está implementado ainda no ACBrFramework, temos planos para fazê-lo em breve, mas só para .Net pois infelizmente não temos equipe para manter o projeto em java. De toda forma, o jACBrFramework vem sendo mantido apenas com o ECF parcialmente implementado, e com um projetinho de exemplo. Dê uma olhada nisso: Saiba mais sobre o ACBrFramework: http://acbrframework.sourceforge.net Como baixar o código fonte: http://acbrframework...s/codigo-fonte/ Download compilado: http://sourceforge.n...ramework/files/ Abs!

Bom dia Valdecir, Cara deixa eu tentar te ajudar: 1- A ACBr32.dll não existe mais há quase 1 ano. Esse projeto deu lugar para o ACBrFramework, e não se limita apenas a uma DLL, é um framework completo de alto nível para ser usado em várias linguagens e plataformas. 2- Não faz sentido nenhum usar a ACBr32.dll no C#, pois existe o ACBrFramework.Net que é a suite com atualmente 17 componentes do ACBr portados para .Net e com suporte completo a todo a a API (classes, propriedades, métodos, eventos, enums, etc) do ACBr. Dê uma atualizada aí: Saiba mais sobre o ACBrFramework: http://acbrframework.sourceforge.net Como baixar o código fonte: http://acbrframework.sourceforge.net/downloads/codigo-fonte/ Download compilado: http://sourceforge.net/projects/acbrframework/files/ Abs!

Obrigado Isaque, Nós terminamos de implementar no ACBrFramework todos os registros e listas do SpedFiscal, o método SaveTXTFile e o evento OnError. Com isso já dá pra funcionar alguma coisa. Outras coisas ficaram ainda de fora nessa versão inicial, e eu gostaria que você nos esclarecesse alguns pontos: - Métodos IniciaGeracao() e WriteBlocoXXX(): Apenas o SaveTXTFile foi incluído nessa versão do Framework, e pelo que notei ele faz essas chamas internamente. Em qual situação o desenvolvedor fará uso desses métodos separadamente? - Eventos dos blocos: Ainda não incluímos os eventos, e na verdade não sei ao certo em qual situação usá-los. - Métodos LocalizaRegistroXXX() das listas de registros: Notei que são úteis para evitar registros duplicados, vamos incluí-los na próxima versão. Abs

Correção enviada ao SVN, pode baixar os fontes e testar novamente. Inseri o projeto "ACBrFramework.Net.SpedFiscalTeste" na solução, ainda está inacabado mas já dá pra testar algumas coisas. Abs

Obrigado pelo demo Luiz Paulo, Constatei aqui e é bug sim, já comito uma versão corrigida. Abs

Ok Corrigido, pegue a última versão aí. Tente novamente e qualquer coisa poste aqui pra gente. O método SaveTXTFile não deve disparar erro, se disparar será um bug. Pra pegar os erros de validação do arquivo use o evento OnError que retorna a mensagem tratada. Obrigado, Abs!

Pessoal, Está disponível a versão final do ACBrSpedFiscal no ACBrFramework.Net. Baixem os fontes pelo SNV e confiram! Ainda estamos em período de debug, portanto reportem os erros encontrados. Em breve teremos o aplicativo de Demo do SpedFiscal. Abs!

Alberto, Baixe o ACBrFramework pelo SVN e dê uma olhada no demo do jACBrFramework, Coloque um exemplo aí de onde está seu fonte e onde está o JNI, Abs

O classpath não é o subdiretório LIB, mas sim a raiz de seu projeto, onde iniciam os packages. Copie a dll do JNI pra lá. Por exemplo: se seu projeto tem uma classe assim package MeuProjeto; public class MinhaClasse { ... } Ele deve estar numa estrutura assim: c:\Fontes\MeuProjeto\MinhaClasse.java Então a raiz do seu classpath é c:\Fontes, basta copiar o ACBr_JNI.dll pra lá. A ACBr32.dll pode ficar ali também ou no PATH do windows, como c:\Windows\System32 por exemplo, mas evite manter várias cópias pra não confundir. o java.exe também permite informar um classpath alternativo pela linha de comando. Abs.

Resposta no outro post, por favor continue por lá:

Alô xmaxmex ... Cara, a versão do ACBrFramework32.dll compilada para STDCALL foi descontinuada Porquê isso? Por que conseguimos uma solução muito elegante e funcional utilizando o ACBrFramework.Net via ActiveX. Dá uma olhada no outro post sobre o assunto, e baixe o exemplo em VB6 no SVN, vale a pena, pois essa versão dá suporte a todo o componente ECF inclusive a eventos. **** Deixo aqui um pedido aos usuários desse projeto, para que por favor participem mais do fórum postando seus problemas, necessidades e modificações feitas no projeto, pois só assim poderemos incorporar as mudanças ao SVN. É o terceiro caso recente de usuário que utiliza alguma versão modificada da antiga do ACBr32.dll que não é mais compatível com o projeto atual que mantemos no SVN. Lembrando que o ACBrFramework atual dá suporte a dezenas de componentes (não só ao ECF como o ACBr32.dll), se concentrarmos os esforços, todos serão beneficiados. Abs!

Oi Alberto, boa tarde. 1) O problema de java.library.path está relacionado ao seu CLASSPATH no java. No java, a dll do ACBr_JNI precisa estar no root do seu classpath. Um erro comum é colocá-la no Windows\System32 por exemplo. 2) Não entendi o que você quis dizer com "adquiri o PAF-ECF Java" ... Poderia explicar melhor o quê você está fazendo ? 3) Pelo visto você utiliza uma versão muito antiga, o ACBr32_JNI não existe mais. Atualmente nosso projeto chama-se ACBrFramework, e o projeto em java é o jACBrFramework, com várias mudanças e melhorias. Baixe a versão pelo SVN e dê uma olhada nas novidades. Abraços,

Parabéns André, e parabéns mais uma vez pois você foi o PRIMEIRO USUÁRIO DO ACBrFramework a homologar o PAF!!! Valeu a confiança nesse projeto, com isso todos nós ganhamos, pois temos um produto cada vez mais sólido e testado! Abs!

É, nesse caso não temos muito o que fazer. Deve ter sido alguma modificação que você fez nos fontes que incompatibilizou com as versões mais novas. (...) Deixa eu dar uma sugestão: Se você baixar os fontes originais do ACBr e ACBrFramework conforme o SVN, compilar tudo sem as modificações e rodar o ECFTeste por exemplo, funciona? Se funcionar, suas modificações causaram algum problema, basta você revisá-las para implementar novamente de acordo. Se não funcionar, é coisa de ambiente, pode ser sua máquina ou alguma coisa instalada errado. (...) Para evitar esse trabalho de revisão em caso de incompatibilidades, eu encorajo fortemente os usuários a compartilhar as alterações feitas aqui no fórum. Assim nós podemos incorporá-las ao SVN e mantê-las funcionando sempre. Abs

Não entendi a questão. Você consegue compilar a ACBrFramework32.dll ? Access violation exatamente onde? O ACBrFramework.Net compila corretamente? ACBrETQ? (...) Coisas que talvez te ajude: A dll nativa ACBrFramework32.dll e ACBrFramework64.dll só compilam em CDECL agora. A versão STDCALL foi descontinuada em favor com COM Interop com C# (vide outro post sobre isso) A ACBrFramework.Net.dll coloca a dll nativa como um recurso embutido nela, e a utiliza em tempo de execução. Dessa forma não precisa distribuir a DLL nativa e a DLL .Net, apenas um arquivo contempla os dois. Cuidado com alguma versão antiga da DLL nativa em seu PATH, pois o SO vai usar esta ao invés da versão embutida. Qualquer alteração na dll nativa, você deve recompilá-la e recompilar a dll .Net depois. (de vez em quando o VS mantém a DLL nativa em uso o que impede da runtime atualizar a versão recém compilada. Nesses casos só fechando e reabrindo o VS) Em máquinas com SO 64bits, você deve compilar seu executável para x86 (ao invés de AnyCPU), pois senão ele não é capaz de carregar a DLL nativa de 32bits. Abs,

Opa, falha nossa! O projeto de exemplo ECFTeste foi colocado em modo Console pra .... fazer um teste Já arrumei, baixe novamente pelo SNV, e fique sossegado a aplicação é um Windows Application nativo sem tela do DOS! Abs