Rafael Batiati

Então você estava com 2 dlls instaladas no seu sistema, a versão 4.0 e a versão 3.5. No caso do VB6, você não precisa registrá-la no GAC, desde que use o Regasm /codebase e não remova a dll da pasta onde ela foi registrada. Abraços.

Opa, falha nossa ... baixe novamente a DLL, mesmo endereço http://sourceforge.n...OM.zip/download O erro que você reportou na geração do TLB foi resolvido. Agora, o erro "Automation Error (80131040)". Tente verificar se a DLL não está duplicada em mais de um lugar. A instalação de ActiveX costuma ser fácil quando funciona, e terrível quando não funciona. É interessante pra gente levantar e documentar os possíveis problemas e soluções. Abs!

@alexcassou Cara, pelo que está parecendo, você está usando a ACBrFramework.Net errada. Existe uma versão própria dela compilada como "COM Interop", que só expõe os tipos já suportados no interop (dá uma olhada no primeiro post). Se você está compilando sua versão da DLL, dá uma checada nisso. Se você baixou a DLL, verifique se o link de download foi para o ACBrFramework.Net.COM.zip http://sourceforge.net/projects/acbrframework/files/ACBrFramework.Net.COM.zip/download (...) Só pra constar, você precisa apenas do Microsoft.Net Framework v3.5 instalado. Abs.

Pessoal, sem essa, todo mundo aqui tem voz, direito e dever de opinar! @markapollo Não estamos discutindo aqui se você deve ou não continuar com seu próprio projeto particular, inclusive sua observação de baixa performance usando o CAPICOM é valiosa... É muito bom que todos que os usuários reportem seus problemas e experiências. O que é a pauta desse tópico, é qual a melhor forma de atualizar o ACBr para funcionar em 64bits e também não precisar mais do descontinuado CAPICOM. Esse é o momento de colaborar: Alguém tem alguma sugestão para fazer isso em .Net de forma que os usuários de Delphi e do ACBrMonitor também possam aproveitar? E quanto ao Linux? Isso não é torcida de time de futebol ... eu no momento tenho uma opinião, mas posso estar cego e não vendo a solução mais simples. Tenham certeza que colaborarei com o que estiver a meu alcance. Abraços.

No ACBrFramework.Net ou no jACBrFramework nada é reescrito, apenas as chamadas de Interop são feitas num modelo de classes semelhante ao do ACBr em Delphi. Não há uma única linha de código referente a regra de negócio dos componentes ... Poderíamos fazer muita coisa diretamente em .Net ou em Java, mas nosso objetivo principal é fazer o Interop do ACBr garantindo o mesmo comportamento e resultado do componente original. No meu ponto de vista, o ACBr já tem muitos anos de estrada, e deveríamos aproveitar essa experiência. Implementar a mesma coisa em plataformas diferentes, mesmo que seja mais fácil a princípio, pode nos levar a resultados diferentes e debug mais custoso. Hoje um bug detectado por um usuário é corrigido de forma ampla em todas as plataformas. Dessa forma, as funções precisam ser implementadas a partir do Delphi/Lazarus, para que todo o ACBr possa se beneficiar disso. Fazer pontos isolados em .Net ou Java só vai fragmentar o projeto em diversas soluções isoladas. Abs!

Pessoal, só pra jogar mais lenha na fogu.... errr ... só pra esclarecer o negócio aí: 1. Estamos trabalhando para compilar e funcionar tanto o ACBr quanto o ACBrFramework em 64 bits. Essa é uma necessidade que foi "adiada" por algum tempo. Em Delphi e Lazarus é bem mais cômodo compilar e distribuir em 32bits. No .Net eu também não vejo tanta vantagem em distribuir em AnyCpu ou x64. Inclusive é uma desvantagem enorme ter que depender de DLLs de terceiros em 64bits. Mas em alguns casos, como no Java por exemplo, isso começou a ser um problema, pois a maioria das máquinas x64 rodam um JRE 64bits, e ter que ficar selecionando o JRE de 32bits pra executar é algo indesejável para um projeto que propõem a multiplataforma ... Isto posto, estamos procurando e testando as dlls 64 bits que o ACBr utiliza ... (veja a pasta DLL na raiz do projeto ACBr) A maioria delas já possui uma distribuição 64 bits... as outras que não possuem estamos buscando soluções equivalentes. Em breve vamos atualizar o SVN adicionando as versões 64bits de todas elas. 2. CAPICOM versus .Net O CAPICOM, ou melhor, o finado CAPICOM, nada mais é que um ActiveX para manipular a Microsoft CriptoAPI. Essa CriptoAPI, também conhecida como "CAPI" é a base do Windows Cryptographic Service Provider, uma API em C/C++ padrão na plataforma Windows a partir do Windows 2000 ... a mesma API que o .Net usa em alguns algoritmos de criptografia dele. Daí vem o nome do ActiveX: CAPI + COM = CAPICOM. E como todo ActiveX, ele não é compatível com 64bits, só 32bits mesmo. Então temos a opção de continuar usando a CAPI diretamente, sem ActiveX, usando as declarações em Delphi (pesquisei por alto, mas vejam o link abaixo) http://cc.embarcadero.com/item/17598 Ou temos a opção de buscar outros projetos que façam o serviço, como a openssl que o ACBr já usa para assinaturas e o openSC para manipulação de SmartCards e tokens. https://www.opensc-project.org/opensc (...) Ou seja, ainda temos um bom trabalho pela frente até ter tudo definido. No momento nós estamos ainda "em pesquisa". É possível colaborar das seguintes formas: - Quem tiver disponibilidade para compilar e testar em x64 e depois reportar os bugs ... ECF, DISPLAY, EAD, NFe, etc... acho que todos os componentes sofrerão algum impacto em x64. - Quem quiser se aventurar a usar o CAPI diretamente ou a openSC, podemos abrir um novo tópico aqui pra trocar uma idéia de como fazer as chamadas a partir do Delphi. É isso aí, abraços!

Oi Valdecir, Dê uma olhada no fórum específico sobre o ACBrTEFD, lá tem muita coisa já respondida. As DLLs e config.ini devem ficar junto do executável. Abs!

Valeu pelas dicas pessoal. Na verdade estou usando o MD5 ainda, só que ao pegar os 32 bytes gerados por ele, eu computo novamente outro hash para chegar em um valor menor, um int de 2 bytes; Vai aumentar a colisão sim (a lei de murphy está aí pra isso), mas no cenário de validar as alterações de N campos de 1 registro, acredito que o custo X benefício valerá a pena. Abs!

Pessoal, desculpe por ressuscitar o tópico. Mas no momento estou "bolando" o jeito de fazer valer o Bloco VII. Pretendo usar outro algorítmo diferente do MD5 para validar a alteração do registro. O MD5 gera 32 caracteres por registro, o que aumentaria muito o tamanho final de meu banco de dados. Pretendo gerar um hash de 16bits (1 short int por registro) com o objetivo de reduzir esse impacto. Pergunta: Há a estrita necessidade de se implementar um MD5, ou se as alterações segundo o roteiro de testes forem evidenciadas estará OK? Abraço a todos!

Oi Andre, que bom que isso esteja sendo útil para você. Vamos lá: O ACBr é uma suite de componentes para automação comercial escrita em Object Pascal, utilizada em Delphi e Lazarus. O ACBr vai muito além de ECFs apenas, tem dezenas de componentes para os mais diversos fins dentro da automação comercial. Nós que trabalhamos com C# .Net, ficávamos com água na boca de toda a facilidade que os usuários de Delphi tinham para manipular qualquer modelo de ECF e ainda criar os arquivos do PAF, etc, etc... decidimos então botar essa brincadeira pra valer no .Net também. Reescrever tudo do zero sem chances, primeiro por que teríamos um trabalhão monstro, depois que teríamos que debugar tudo novamente, perdendo toda a experiência de vários anos e inúmeros usuários que o projeto ACBr já possui. Então decidimos criar uma "Camada de Interoperabilidade" do Object Pascal (Delphi) com qualquer linguagem de programação. Funciona mais ou menos assim: Criamos uma DLL nativa a partir do ACBr, essa ACBrFramework32.dll que você viu. Como essa DLL é muito complexa para ser utilizada diretamente, um modelo de objetos semelhante ao ACBr original é criado tanto em C# quando em Java (chamamos isso de wrapper). A partir desse wrapper você manipula a DLL seja em C# ou em Java da mesma forma que um programador Delphi usa o ACBr, ou seja, você pode usar um exemplo escrito em Delphi ou fazer uma pergunta em qualquer área do fórum que o comportamento e modo de usar será exatamente o mesmo em qualquer linguagem. Por isso não há razão para usar a DLL nativa ou as classes de interop diretamente. Elas são apenas para fins de desenvolvimento. A DLL é embutida no ACBrFramework.Net, de forma que você não precisa copiá-la para nenhum lugar. O próprio componente a extrai numa pasta temporária e a utiliza sem que o usuário saiba. Caso queira estudar o fonte, está incluído no SVN do ACBrFramework, é o projeto feito em Lazarus. Sinta-se a vontade para usar e perguntar. Leia também os outros posts do fórum para se familiarizar aos componentes do ACBr e aprender tudo que dá pra fazer com eles. Abs,

http://acbrframework.sourceforge.net/

O componente da NFe do ACBr é capaz de emitir, assinar, enviar, imprimir e gerar o XML da nota fiscal ... mas ainda está em desenvolvimento. Nem mesmo o XML você será capaz de gerar no momento com o ACBrFramework, pois o nosso principal trabalho é em criar o modelo de classes para o interop, então você não terá como setar todos os campos necessários ainda. Caso queira, dê uma olhada no NFeMonitor, é um outro projeto do ACBr que poderá te ajudar. Abs.

@vasilvei Muito bom o código, já foi incluído no SVN, pode pegar a última versão que sua alteração estará lá. Pelo visto você entendeu perfeitamente como funciona ... mas qualquer dúvida é só postar aqui. Apenas uma mudança que fiz, o método getAliquota() foi renomeado para getAliquotas() por causa da compatibilidade com a API original, cuja propriedade chama-se Aliquotas. Obrigado pela contribuição, Abs.

Sim, pode dar uma olhada nos métodos getFormasPagamento(), carregaFormasPagamento(int count) e na classe FormaPagamento que seguem a mesma lógica de uso de structs das Alíquotas, RelatorioGerencial e ComprovanteNaoFiscal. Caso queira implementar, poste o código aí pra gente que incluímos no SVN depois. Abs

Isso entra no que eu disse no primeiro post "Faltam alguns ajustes nos métodos que retornam/recebem classes complexas."

Pesquisando sobre o estado do RJ, Fica difícil se entender no meio de tanta lei .. Abraços

Oi Elton, obrigado. Entendi que só posso colocar o ECF em operação em outro CNPJ mediante compra do equipamento de terceiros e terei que trocar o MFD. Mas não fala nada da situação de desenvolvimento, onde o ECF vai funcionar sem lacre apenas para testes de software... E não sei se na homologação o fato de estar lacrado ou sem lacre, no meu CNPJ ou de outro tem algum problema.

Pessoal, Estou precisando comprar um ECF pra desenvolvimento e surgiu a oportunidade de comprar um ECF usado de um cliente que fechou a loja. Alguém sabe se poderei usar esse ECF com o CNPJ do cliente na homologação?? Abs!

Temos previsão sim, 90% do código do ACBrECF foi gerado pelo nosso DefExporter. Código em java para propriedades, métodos e eventos são gerados automaticamente baseada em convenções de nomes extraídas a partir do metadata do componente feito em .Net; Isso facilitou muito o nosso trabalho. Mas temos ainda que implementar a geração no caso de classes complexas (as ComposedComponents) e no caso de structs. Esses dois pontos são largamente usados em componentes como o AAC, PAF e EAD. Ou seja, dentro em breve teremos praticamente todos os componentes implementados em Java. Abs.

Não temos esse tipo de demo, você pode documentar e postar aqui um tutorial, será bem vindo. Acho que o ACBr no momento não está compilando em 64bits, por causa de funções nativas implementadas somente em 32bits .... será resolvido, mas no momento só via 32bits mesmo. Não sei no linux, mas creio que idem.

As classes Interop não são para serem usadas diretamente dessa forma, elas precisam ser encapsuladas num modelo de objeto que reproduza o comportamento do componente PAF do ACBr. O componente ACBrPAF ainda não está implementado no Java, e a classe ACBrPAFInterop foi gerada automaticamente a partir do DefExporter, então, nesse momento é bem capaz de precisar de um trabalho de debug nessas assinaturas do Interop. Dessa forma aconselho você, caso queira desenvolver o componente PAF, trabalhar sobre um modelo de classes condizente com componente ACBrPAF ao invés de usar a classe interop diretamente no seu código. As APIs dos componentes são públicas serão mantidas compatíveis com novas versões no futuro, já as APIs do interop são privadas e podem mudar livremente de acordo com o design do projeto. Você corre o risco de ter que reimplementar tudo isso quando o componente for liberado pra uso. Olhe o componente ACBrECF e veja a idéia por trás do uso do Interop.

Pessoal, Boas novidades. O projeto jACBrFramework passou por um grande refactoring, foi praticamente refeito do ZERO com novas classes bases e reorganização dos pacotes. A classe ACBrECF (que agora fica no pacote jACBrFramework.serial.ecf.ACBrECF) está com todas as propriedade e métodos implementados. Faltam alguns ajustes nos métodos que retornam/recebem classes complexas. Agora temos também suporte a eventos no Java (via Listeners), todos os eventos disponíveis foram adicionados ao componente ACBrECF, veja no exemplo como utilizá-los. (...) Com essas alterações novos componentes poderão ser adicionados mais facilmente, dispensando o uso de C++ para as chamadas nativas. Aos usuários do antigo jACBr ou da última versão do jACBrFramework que ainda dependia da ACBrFramework_JNI.dll, peço que atualizem seus projetos. Esta versão atual está muito melhor e mais fácil de manter. Baixem os fontes e confiram (agora com projeto NetBeans incluído). Por link direto http://sourceforge.net/projects/acbrframework/files/jACBrFramework.zip/download Ou pelo SVN http://acbrframework.sourceforge.net/downloads/codigo-fonte/ Qualquer dúvida/problema é só postar por aqui. Abs

Por que você precisaria desse método? Use o componente ACBrPAF

@ Rodrigo, tem certeza que você atualizou os fontes? o ACBr.Net não existe mais, o projeto correto é ACBrFramework.Net, e ele possui todas as funções do ECF implementadas, inclusive essa que você procura. O endereço do SVN mudou também, pode ser que você esteja tentando baixar a coisa errada. Por favor, dê uma lida em Projeto ACBrFramework http://acbrframework.sourceforge.net/ Download direto da versão compilada http://sourceforge.net/projects/acbrframework/files/ACBrFramework.Net%20Install.vsi/download Como baixar o código-fonte http://acbrframework.sourceforge.net/downloads/codigo-fonte/ Abs.

O componente ACBrDIS foi incluído no ACBrFramework.Net. Baixe a última versão pelo SVN e confira. Como não possuo um Display, não pude testar o componente a contento, apenas usei o modelo = disNenhum que me permitiu emular o comportamento dele. Verifique se está ok e qualquer coisa poste aqui. Abs.