Rafael Batiati

Se seu windows for 64 bits, não se esqueça de compilar o executável de seu projeto como x86 (32 bits), pois se estiver como Any CPU ele executa em modo 64 bits e impede de carregar módulos (dlls) de 32bits. Mas se seu windows for 32 bits mesmo, não sei o que pode estar errado. Apenas a dll ACBrFramework.Net.dll já basta, pois ela traz a DLL nativa embutida. Não precisa colocar a ACBrFramework32.dll em nenhum lugar no path. Abs,

Com certeza, Primeiro baixe o código-fonte do projeto, instruções no link abaixo: http://acbrframework.sourceforge.net/downloads/codigo-fonte/ Nós temos feito os exemplos "demos" o mais parecido possível com os demos feitos no ACBr. Nesse caso, para o ECF, se você seguir o ECFTeste no ACBr (em Delphi) ou no ACBrFramework.Net (em C#) fazendo algo semelhante em VB6 será de grande valia para toda a comunidade. Qualquer dúvida, é só postar. Abs!

Pessoal, O ACBrFramework.Net foi modificado para exportar as classes para ActiveX via COM. Agora é possível utilizá-lo em plataformas que suporta componentes COM como VB6 por exemplo. Por enquanto apenas o ECF os componentes ECF, AAC e EAD estão funcionando experimentalmente com suporte a propriedades e a eventos. Para utilizar, é preciso compilar o projeto em C# como "COM Interop" esse modo gera o ACBrFramework.Net.dll e ACBrFramework.Net.tlb o arquivo tlb é usado para referenciar no VB6 por exemplo, em Project > References o arquivo dll deve ser registrado com o utilitário RegAsm.exe, da mesma forma que as DLLs ActiveX são com o regsvr (nada muda!) Você precisa do .Net 3.5 instalado O RegAsm.exe normalmente fica na pasta do .Net (C:\Windows\Microsoft.NET\Framework\v2.0.50727) Basta digitar na linha de comando: C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe c:\Onde_está_sua_DLL\ACBrFramework.Net.dll /codebase Para baixar a DLL compilada: http://sourceforge.net/projects/acbrframework/files/ACBrFramework.Net.COM.zip/download Para baixar os fontes Siga as intruções http://acbrframework.sourceforge.net/downloads/codigo-fonte/ O projeto VB6 está em: https://acbr.svn.sourceforge.net/svnroot/acbr/ACBrFramework/ACBrFramework.ActiveX/ *** Qualquer dúvida, problema, sugestão, estamos aí.

Iniciativa já temos, só não temos "acabativa" por enquanto ... rsrsr Seguem as iniciativas: - O ACBrFramework compila normalmente em Lazarus no Linux e todas as chamadas são em compatíveis com Linux (cdecl ao invés de stdcall). - O código do JNI apesar de ser um projeto em Visual C++ foi feito pra ser compilado em gcc também. Compatível com qualquer plataforma Java. - O ACBrFramework.Net também foi feito pensando pra rodar no Mono, usando o ACBrFramework.so Dessa forma só precisamos mesmo é seguir o caminho pra botar pra funcionar. Eu não tenho muito contato nem habilidade com o Linux, mas estou disposto a ajudar no que estiver a meu alcance. Abs,

Os arquivos de cabeçalho são gerados por uma ferramenta que nós "inventamos", o ACBrDefExporter (ACBrFramework.Net\ACBrDefExporter). Ele pega as APIs declaradas em C# e converte para C/C++ ou Visual Basic, nos poupando trabalho de manter essas versões, uma vez que a versão .Net é quase sempre a mais atual. Uma vez gerados os .h, a DLL pode ser linkada no código JNI a partir de uma .lib exportada por um utilitário chamado DumpBin (ACBrFramework\cLIB). A versão do Lazarus que uso foi a última disponível quando fiz download 1.0.4. Abs

Sim, nesse teste é usado relatório gerencial e não vinculado, pois o vinculado como você mesmo disse, já foi impresso e só pode ser aberto uma vez. Para o TEF toda reimpressão deve acontecer via relatório gerencial. Abs,

Oi vasilvei, Isso é implementação dentro do ACBr e não do ACBrFramework, na classe ACBrECFEpson. Olhei a classe e ela realmente não tem esse método, e normalmente isso ocorre para algum modelo de ECF específico é porquê ele não dá suporte para a ação. Procure ver se é possível realmente realizar essa operação num Epson, aí abra um outro tópico específico disso que a turma que desenvolve os ECFs poderá te ajudar. Abs!

Olhei no código do ACBrECF e está implementado com esse propósito, só imprimir caso seja maior que zero: if InfoRodapeCupom.NotaLegalDF.ValorISS > 0.00 then Rodape := Rodape + ' ISS = ' + FormatFloat(',#0.00', InfoRodapeCupom.NotaLegalDF.ValorISS); Não tenho certeza se o ato cotepe realmente exige isso, CONCESSÃO DE CRÉDITOS – LEI nº 4.159/08. e, na terceira linha, que se torna a primeira se o estabelecimento não estiver incluído no programa de concessão de crédito: NOTA LEGAL: <TRIBUTO> = onde NOTA LEGAL vem destacado em negrito e a variável <TRIBUTO> assume a expressão ICMS ou ISS, tudo em caixa alta, seguido do valor do tributo obtido conforme item 5 do Requisito VIII-B. Exemplo: ESTABELECIMENTO INCLUÍDO NO PROGRAMA DE CONCESSÃO DE CRÉDITOS – LEI nº 4.159/08. NOTA LEGAL: ICMS = 3.000,00 ISS =1.500,00 Mas em todo caso você pode levar sua dúvida ao fórum específico "ACBrSerial e ACBrMonitor", onde com certeza os desenvolvedores do componente ACBrECF vão saber te responder com precisão. Abs.

Pelo visto você atachou o evento com um += ao componente ... depois fechou o form que declarava o método que foi atachado. E quando você chama o evento novamente, ele não consegue usar o controle, pois já foi fechado. Você deve fazer o += para atachar o evento, e ao fechar o form, o -= para remover. Abs

Boa noite Andre, Como assim desativar? No nosso caso, se o evento não for assinado ele também não é processado nem disparado, ou seja, não gera custo pro componente. abs

Provavel que seja o caminho dos seus fontes, Você tem que baixar o conteúdo dos repositórios do ACBr e do ACBrFramework, e colocá-los lado a lado dentro de uma mesma pasta, ex: c:\Projetos\ACBr c:\Projetos\ACBrFramework Abs!

Sim, colocar a dll no mesmo diretório junto da ACBrFramework32.dll.

Infelizmente não há protocolo nos ECFs que permita implementar isso via comunicação direta. Todas as funções MFD necessitam das DLLs do fabricante No diretório do ACBr no SVN (no ACBr, e não no ACBrFramework) há uma pasta "DLLs\ECF" onde estão todas as DLLs dos fabricantes. Você precisa posicionar a DLL do fabricante do seu ECF, no caso a Epson, no seu path, junto da ACBrFramework32.dll. *** Inclusive, deixa eu levantar uma questão aqui ... justamente por essa dependência da dll do fabricante para o MDF, o ACBrFramework e o próprio aplicativo PAF continuam limitados à plataforma da dll do fabricante. Por exemplo, não é possível rodar o jACBrFramework em uma JVM 64 bits nem compilar o ACBrFramework para 64bits pois a DLL de 32bits do fabricante não será carregada corretamente ao emitir uma leitura MFD. Todo o resto funciona, exceto essa dependência. Abs!

O setOperador do jACrFramework é o equivalente à propriedade "Operador" do ACBrECF. Setar essa propriedade apenas faz com que o ECF chame o IdentificaOperador antes de abrir os documentos; O comportamento vai depender do modelo do ECF que você está usando. Como o comportamento do jACBrFramework é o mesmo do ACBr, sugiro você dar uma estudada aqui no fórum nos tópicos sobre o componente ACBrECF, tem muita coisa legal lá. Dá uma lida nesse post: viewtopic.php?f=10&t=1174&hilit=Operador Abs,

Valeu LuizPaulo, projeto de demo simples e direto ao ponto!!! Corrigi o problema nos registros R1 e R2 do PAF, estavam declarados errados no código do ACBrFramework.Net, isso causava o problema. Baixe a última versão do SVN e confira aí se funcionou. Não tem de quê pedir desculpas, estamos aí pra contribuir com o projeto mesmo, a ajuda de vocês é importante pois deixa o código cada vez mais estável. Continuem usando e postando, quanto mais melhor. Aproveitando o bonde, peço para sempre que possível ao postar já adiantar um demo com o código pra reproduzir o erro, pois isso nos poupa um trabalhão até chegar ao real problema. Abs!

Pessoal, Eu uso essa mesma função e não recebo a mensagem de erro. Se puderem anexar um projeto/código fonte pequeno apenas o necessário pra rodar e reproduzir o erro eu dou uma olhada aqui. Abs,

Verifique aí se você está mesmo usando a última versão do SVN (eu fiz o commit desses ajustes ontem a noite, junto do post anterior).

Oi Marcelo, Provavelmente algum campo do registro foi setado como nulo, Para evitar problemas assim, os métodos que enviam as strings para o ACBr foram alterados para permitir trabalhar com valores nulos. Baixe a última versão do SVN e confira. Mas verifique também seu código, pois se o campo for realmente requerido para a operação, você poderá receber outra exception vinda dos componentes ACBr. Abs,

Show de bola, isso aí mesmo. Essa função vc usa do lado do JNI e já expõe ao java o parametro como um java.Util.Date. Terminando aí vc me dá um alô pra eu olhar o código e atualizar aqui no SNV, blz? Abraços.

Dá uma olhada nesse artigo da Microsoft, http://support.microsoft.com/kb/169795/pt?wa=wsignin1.0 Ele tem o código fonte completo de um OleDate, herdando de java.Util.Data, não precisamos de tanto, mas tem a clara implementação do método toDouble que é exatamente o que precisamos. Vê aí se vc consegue, Qualquer coisa, no fim de semana eu dou uma olhada nisso. Abs,

Por favor, não faça a mesma pergunta em vários tópicos. Respondido no outro tópico viewtopic.php?f=19&t=8070&start=20#p45595

Existe no projeto jACBrFramework a classe Util que tem o método doubleToDate que converte um double para um java.util.Date (as datas no Delphi são armazenadas como um double no padrão OLE). Até o ponto que eu implementamos, não tínhamos nenhum método que recebia um Date como argumento, então não chegamos a fazer a função em contraparte dateToDouble Você pode implementar essa função dateToDouble na classe Util, fazendo o inverso da regra implementada em doubleToDate. Só atente ao fato de que é o JNI que chama essa função, no código Java você sempre deve trabalhar com os tipos de alto nível, ou seja usar um java.util.Date ao invés de usar o double. Dá uma olhada em qualquer função do JNI que retorna data, por exemplo, a Java_jACBrFramework_ACBrECF_getDataHora. Ela usa a função GetDate implementada em JNIHelper.cpp no projeto JNI. Essa GetDate faz uso do método estático Util.doubleToDate para converter o double para java.util.Date, expondo ao Java apenas o tipo correto Date, e nunca o double. Esses métodos Get e Set do JNIHelper são auxiliares para operações comuns de get e set em propriedades dos componentes. Eles acessam via ponteiros de função os métodos com assinaturas já padronizadas, economizando muito código na implementação deles. No seu caso você pode até fazer um SetDate no JNIHelper para usar futuramente em propriedades que setam datas, mas como seu objetivo atual é usar a função ECF_LeituraMemoriaFiscalData, poderá fazer algum outro método no JNIHelper que permita usar apenas o Util.doubleToDate diretamente, sem envolver os ponteiros de função, já que a assinatura da função em questão é muito específica. Qualquer dúvida, posta aqui pra gente. E depois pode anexar seu código para atualizarmos o SVN com esses métodos. Abs,

Existe no projeto jACBrFramework a classe Util que tem o método doubleToDate que converte um double para um java.util.Date (as datas no Delphi são armazenadas como um double no padrão OLE). Até o ponto que eu implementamos, não tínhamos nenhum método que recebia um Date como argumento, então não chegamos a fazer a função em contraparte dateToDouble Você pode implementar essa função dateToDouble na classe Util, fazendo o inverso da regra implementada em doubleToDate. Só atente ao fato de que é o JNI que chama essa função, no código Java você sempre deve trabalhar com os tipos de alto nível, ou seja usar um java.util.Date ao invés de usar o double. Dá uma olhada em qualquer função do JNI que retorna data, por exemplo, a Java_jACBrFramework_ACBrECF_getDataHora. Ela usa a função GetDate implementada em JNIHelper.cpp no projeto JNI. Essa GetDate faz uso do método estático Util.doubleToDate para converter o double para java.util.Date, expondo ao Java apenas o tipo correto Date, e nunca o double. Esses métodos Get e Set do JNIHelper são auxiliares para operações comuns de get e set em propriedades dos componentes. Eles acessam via ponteiros de função os métodos com assinaturas já padronizadas, economizando muito código na implementação deles. No seu caso você pode até fazer um SetDate no JNIHelper para usar futuramente em propriedades que setam datas, mas como seu objetivo atual é usar a função ECF_LeituraMemoriaFiscalData, poderá fazer algum outro método no JNIHelper que permita usar apenas o Util.doubleToDate diretamente, sem envolver os ponteiros de função, já que a assinatura da função em questão é muito específica. Qualquer dúvida, posta aqui pra gente. E depois pode anexar seu código para atualizarmos o SVN com esses métodos. Abs,

Trk, não tem de quê! Mas, só pra eu entender tb!!! rsrsrsr Era isso mesmo? impressão de vinculado com compra parcelada no cartão? abreCupomVinculado(coo, cofFormaPag, valor) O valor passado é sempre integral, e não o valor das parcelas. Abs!

Opa, que bom, gosto de ver a comunidade Java na ativa !!! heheehe Vamos lá ... Eu não entendi sua pergunta. Tenta me esclarecer: O cupom vinculado é pra imprimir o texto retornado pelo TEF? Se for eu acredito que não terá diferença pra você se o pagamento for em 1 ou 12 parcelas, uma vez que no ECF haverá apenas 1 pagamento registrado, e essa informação de parcelamento vai constar apenas no texto retornado pelo TEF, sem interferência sua. Fico no aguardo... abs!