PC Toledo

Eu tenho ele instalado aqui. Cheguei a abrir a dll nele, mas não entendi bem o retorno.

E apenas a título de curiosidade, apenas digitei no navegador, nem vi que era o bing.... rs
Aparece logo no início.

Quintas, foi daí mesmo que baixei, vi que é para uso com a MP 4200 TH.
A questão é a seguinte:
1) Ao carregar a mp2032.dll (4.4.0.2) usando hb_libload(), com Harbour 3.2, acusa o erro.
2) Ao carregar a mp2032.dll (2.0.3.23) usando hb_libload(), com Harbour 3.2, funciona corretamente.
3) Conforme seu teste, ao carregar a mp2032.dll (4.4.0.2) usando hb_libload(), com Harbour 3.4, também
funciona.

Então isso aponta incompatibilidade entre a versão atual da dll e o Harbour 3.2?

Obs: Testei seu exemplo com o Harbour 3.2 e também acusa o erro.

Atenciosamente,

Aqui rodei na pasta d:\temp, no mesmo local aonde descompactei o ZIP da bematech.
tem o exe, as dlls, o ini, etc.

Por precaução, adicione -w3 -es2 na compilação pra confirmar que está tudo ok com os #define ao usar Harbour 3.2.

Xiiiiiiii
Harbour 3.2, o que tinha aqui, o que tava na mão.
Até apaguei o EXE pra confirmar se era realmente Harbour 3.2 e não o anterior.

Sei lá se faz diferença:

Windows 10 64 bits, 1703, build 15063.502

Harbour 32 bits, mingw

André,

Veja se com o programa abaixo, você consegue alguma informação útil:

https://docs.microsoft.com/en-us/sysint ... s-explorer

Ele mostra os processos em execução. Basta selecionar o processo (seuprograma.exe, por exemplo) e ele mostrará as dll's carregadas por ele (CTRL-L mostra/esconde esta seção).

Além de mostrar as dll's carregadas, ele mostra de onde (path) a dll foi carregada. Isto ajuda com problemas de carregamento de dll's erradas (pensamos que está usando uma, mas está usando outra de outro caminho).

Também tem o jeito antigo:
Procurar tudo no disco e apagar antigos (ou zipar pra deixar guardado).
Assim resolve algum problema atual e futuro de uma vez.... rs

Bom dia pessoal,

Descobrimos qual é o problema:

Nós mantemos as dlls de comunicação separadas em pastas específicas, elas não ficam no
diretório do executável do sistema.
Antes de carregar a dll com o HB_LibLoad(), alteramos o diretório corrente usando o DirChange()
e apontando o diretório onde elas estão, devido justamente a poderem precisar carregar outras dlls.
No HB_LibLoad(), passamos o caminho completo.

Ex: Nos testes, acabamos descobrindo que na versão atual da mp2032.dll, a SiUSBXp.dll precisa estar no diretório do
executável do programa. Mesmo usando o DirChange(), ocorre o erro se ela estiver em outro diretório.
Para testar, basta colocar as dlls em outro diretório, que não o do executável de teste, usar o DirChange() apontando para
ele e passar o caminho completo no HB_LibLoad().
Alguém sabe se existe alguma forma de contornar isso, já que o DirChange não resolve?

Obrigado,

Vai usar mais de uma versão da mesma DLL?
Deixe na pasta do aplicativo e não complique.
Ou....
entre em contato com o fabricante pra ver se existe outra opção.

Se inventar gambiarras, lembre-se que vai depender do sistema operacional aceitar, e outras coisas mais.
Mas no momento, quem decide isso é a DLL do fabricante, e não o Harbour.

Ou.... outra gambiarra: deixe um EXE de impressão da pasta da DLL, de repente será o mesmo que usar um aplicativo ACBR ou algo parecido.

Quintas,

A intenção é utilizar apenas a versão mais atual da dll.
Nós seguimos esse padrão de ter tudo organizado em pastas específicas para não ficar espalhado no diretório do executável.
Funciona com todas as dlls que utilizamos até agora, tanto para comunicação com ECF/Impressora não fiscal, quanto com outros
equipamentos, de diversas marcas, como Daruma, Elgin, Dimep, Epson, Sweda, etc, etc. E funciona com a versão anterior da
dll da Bematech.
Vou entrar em contato com o suporte da Bematech para tentar encontrar uma solução para manter o padrão que seguimos.
Se não tiver, paciência, usamos a versão anterior da dll (que funciona corretamente) ou colocamos no diretório do executável.
Criar um executável à parte apenas para impressão não é interessante.
Obrigado pela ajuda.

Atenciosamente,

Vai ser difícil, mas talvez eles fornecerem os fontes dessa DLL.
À primeira vista, a que precisa é a outra, e essa é apenas uma intermediária.

Outra opção seria renomear as DLLs que podem ser renomeadas.
Pelo menos deixaria a pasta organizada, mesmo com muitas DLLs.

Por exemplo Printer_Bematech_2032.dll
Todas as DLLs de impressora estariam juntas em ordem alfabética como Printer_

André,

Veja se a página abaixo ajuda na busca por uma solução:

https://msdn.microsoft.com/pt-br/librar ... s.85).aspx

Ela descreve como o Windows lida com o carregamento de dll's e as regras usadas (veja a seção 'Standard Search Order for Desktop Applications').

Em resumo, há dois modos: SafeDllSearchMode habilitado ou desabilitado. Quando habilitado, o diretório corrente está na quinta posição. Quando desabilitado, está na segunda.

SafeDllSearchMode habilitado é uma proteção. O ideal é mantê-lo habilitado, para não abrir brechas para programas maliciosos.

Obrigado Marcos,

Vou dar uma estudada em quê isso poderia implicar, pois usamos o DirChange() para
alterar o diretório antes de carregar as dlls. E se confirmar com o CurDir(), retorna o
diretório correto.

Marcos,

Muito obrigado pela dica. Encontramos a solução na página citada, em particular, no trecho transcrito abaixo.

Se uma DLL tiver dependências, o sistema procura as DLLs dependentes como se estivessem carregadas apenas pelos nomes dos módulos. Mesmo se a primeira DLL foi carregada especificando um caminho completo.

Se não for indicado internamente, no código da dll principal, o sistema busca as dependências pelos nomes, esperando que já estejam carregadas.

Foi necessário apenas carregar a dependência (SiUSBXp.dll) antes da dll principal (mp2032.dll).

Obrigado a todos que responderam.