Exemplo de utilização ACBr32.dll

Jackson_rr · 2 Novembro, 2012

Ola Rafael

Tenho para varias ECF o .C das chamadas da DLL do fabricante, só por curiosidade, por que não usar a DLL do fabridante, a comunicação não seria mais rápida, pois temos situações em que tem que ter a DLL do fabricante.

Para qual ECF você quer ?

outra coisa, mesmo a DLL do fabricante não devolve em ARRAY somente em STRING, por isso proponho o retorno no caso complexos, por exemplo

FORMAS DE PAGAMENTOS

ALIQUOTAS

e outros, pode retornar uma STRING separada por "|" igual ao ACBRMonitor faz, pois fica facil transformar para ARRAY se nescessário for.

Fico no aguardo

======================================================================

[]___

/ /\____ Jackson Douglas C. Brito

/_/\_//____/\ Engenheiro de Soluções

| || ||| ||| OnTop Sistemas / Wild Sistemas

| || |||__||| Boa Vista - RR (95)-8112-8570

======================================================================

Daniel Simoes · 7 Novembro, 2012

Alguns motivos que me levaram a não usar a DLL do fabricante no inicio do ACBrECF...

- Incompatibilidade com Linux

- Lentidão em algumas DLLs

- Perda de controle da aplicação em algumas DLLs

- Dificuldade de configuração de Porta e outros parâmetros (algumas DLLs usam .INI, outras .XML outras o Registry)

- Incompatibilidade entre os comandos (similares) de algumas DLLs

- DLL hell (as instruções de instalação da DLL nem sempre são claras e variam de acordo com o S.O.)

A proposta de abolir os tipos complexos aumenta a compatibilidade, mas torna o uso do FrameWork mais difícil para as linguagens de alto nível... e quebraria todo o projeto atual.... A ideia é ter algo semelhante ao componente ACBrECF (do Pascal) nas linguagens que suportem o FrameWork ...

Talvez você possa iniciar um novo projeto, usando apenas pchar como parâmetros e as DLLs dos Fabricantes... entretanto observe que atualmente o ACBrFrameWork suporta vários outros componentes do ACBr... ou seja, não é apenas usado para ECF...