Retorno no ACBrNF32.dll

[jelias]

Olá amigos, desejo e espero encontra-los bem!

Estou desenvolvendo algumas rotinas para o uso do ACBrNF32.dll afim de agilizar a emissão de notas fiscais.
Já no início estou tendo um problema na rotina do método "NFE_StatusServico".
O retorno está sem conteúdo das informações, entretanto noto que o xml que retorna está com o conteúdo certinho da SEFAZ.

Abaixo segue minha rotina: Antes da rotina é executado o comando LoadLibrary("AcbrNFe32.DLL")

Código: Selecionar todos

//-------------------------------------------------------------------------------------------------------------------------------
// Método usado para consultar o STATUS da disponibilidade dos serviços do PORTAL DA SEFAZ
// 
FUNCTION ACBrDLL_StatusServico(lLog)
LOCAL oRetorno:=SPAC(256), nTamanho:=256

IF lLog; ACBrDll_GeraLog(1); ENDIF
IF DLLCALL( "ACBrNFe32.dll", 32, "NFE_Inicializar", "ACBrNFeLIB.Ini", "" ) #0
   MENSAGEM("Erro ao inicializar a ACBrLib, verifique! ")
   retu oRetorno
ENDIF 
IF DLLCALL( "ACBrNFe32.dll", 32, "NFE_StatusServico", @oRetorno, @nTamanho ) #0   
   MENSAGEM("Erro ao executar o método NFE_Status",3) 
ENDIF
IF lLog; ACBrDll_GeraLog(2); ENDIF
RETURN oRetorno

Arquivo de log onde pode-se ver que não retorna as informações na variável oRetorno. Deixei em negrito o conteúdo da variável para não repetir informação.

Código: Selecionar todos

23/01/26 14:42:37:535 - TLibNFeConfig.AplicarConfiguracoes: F:\sistema\ACBrNFeLIB.Ini
23/01/26 14:42:37:536 - Travar
23/01/26 14:42:37:590 - TLibNFeConfig.AplicarConfiguracoes - Feito
23/01/26 14:42:37:615 - Destravar
23/01/26 14:42:37:641 - TLibNFeConfig.Ler - Feito
23/01/26 14:42:37:668 - Destravar
23/01/26 14:42:37:694 - TACBrLibNFe.Inicializar - Feito
23/01/26 14:42:37:720 - LIB_Inicializar( ACBrNFeLIB.Ini,  )
23/01/26 14:42:37:784 -    ACBrLibNFE - 0.4.6.277
23/01/26 14:42:37:811 - NFE_StatusServico
23/01/26 14:42:37:837 - Travar
23/01/26 14:42:38:118 -    MoverStringParaPChar. StrLen:111, BufLen:256
23/01/26 14:42:38:118 -    SetRetorno(0,[b] [Status]
CStat=0
CUF=0
DhRecbto=
DhRetorno=
Msg=

TMed=0
VerAplic=
Versao=
XMotivo=
XObs=
tpAmb=1[/b]
)
23/01/26 14:42:38:165 - Destravar
23/01/26 14:42:38:197 - TLibNFeConfig.AplicarConfiguracoes: F:\sistema\ACBrNFeLIB.Ini
23/01/26 14:42:38:219 - Travar
23/01/26 14:42:38:248 - TLibNFeConfig.AplicarConfiguracoes - Feito
23/01/26 14:42:38:274 - Destravar
23/01/26 14:42:38:301 - TLibNFeConfig.Ler - Feito
23/01/26 14:42:38:330 - Destravar
23/01/26 14:42:38:359 - TACBrLibNFe.Inicializar - Feito
23/01/26 14:42:38:388 - LIB_Inicializar( ACBrNFeLIB.Ini,  )
23/01/26 14:42:38:416 -    ACBrLibNFE - 0.4.6.277
23/01/26 14:42:38:446 - TACBrLibNFe.PrecisaCriptografar(Principal,LogNivel)
23/01/26 14:42:38:512 - TACBrLibNFe.PrecisaCriptografar - Feito Result: False
23/01/26 14:42:38:542 - LIB_ConfigGravarValor(Principal, LogNivel, 0)
23/01/26 14:42:38:576 - TACBrLibNFe.PrecisaCriptografar(Principal,LogNivel)
23/01/26 14:42:38:604 - TACBrLibNFe.PrecisaCriptografar - Feito Result: False
23/01/26 14:42:38:639 - TLibNFeConfig.AjustarValor(tfGravar,Principal,LogNivel,0)
23/01/26 14:42:38:667 - TLibNFeConfig.AjustarValor - Feito
23/01/26 14:42:38:696 - TLibNFeConfig.AplicarConfiguracoes: F:\sistema\ACBrNFeLIB.Ini
23/01/26 14:42:38:726 - Travar

Caso alguém possa ajudar agradeço antecipadamente"

Saudações,

Júlio.

[JoséQuintas]

Não conheço ACBR mas....
Porque UF=0 ?
Não configurou nada ?

Se fosse sefazclass.... o default é SP, UF=35

[jelias]

Agradeço Mestre Quintas pelas considerações.

A UF é configurada no arquivo INI ACBrNFeLIB.INI e está configurada corretamente na seção pertinente.

Código: Selecionar todos

[DFe]
SSLCryptLib=1
SSLHttpLib=3
SSLXmlSignLib=4
UF=MG
TimeZone.Modo=0
TimeZone.Str=
URLPFX=
ArquivoPFX=f:\nfe\chave\shfkjshdfkjshfkjshf.PFX
DadosPFX=
Senha=IDYFQwRudkA=
NumeroSerie=
VerificarValidade=1

O método "NFE_StatusServico" pelo meu entendimento pega o retorno da requisição em formato XML e passa todo o conteúdo para o primeiro parâmetro que neste caso é a variável @oRetorno conforme o código abaixo:

DLLCALL( "ACBrNFe32.dll", 32, "NFE_StatusServico", @oRetorno, @nTamanho )

Pedi para salvar da requisição, ou seja, o arquivo XML, e a resposta está correta com todos os campos preenchidos. https://acbr.sourceforge.io/ACBrLib/NFE ... rvico.html

Segue abaixo o conteúdo do XML que deveria ser repassado o conteúdo para a variável.

Arquivo F:\sistema\Docs\20260124203624-sta.xml

Código: Selecionar todos

<?xml version="1.0" encoding="UTF-8"?>
-<retConsStatServ versao="4.00" xmlns="http://www.portalfiscal.inf.br/nfe">
<tpAmb>1</tpAmb>
<verAplic>W-3.3.34</verAplic>
<cStat>107</cStat>
<xMotivo>Servico em operacao</xMotivo>
<cUF>31</cUF>
<dhRecbto>2026-01-24T20:40:52-03:00</dhRecbto>
<dhRetorno>2026-01-24T20:40:52-03:00</dhRetorno>
</retConsStatServ>

Saudações,

Júlio

[JoséQuintas]

Confirmou se a configuração de UF é MG ou 31 ?
Isso explicaria aparecer o zero.

[JoséQuintas]

Tentando ajuda no copilot, todo windows tem.
A resposta está meio esquisita, melhor confirmar.

acbr.png (100.44 KiB) Exibido 66 vezes

[jelias]

Mestre Quintas grato pela ajuda!

Fiz a modificação no campo do arquivo INI colocando o código numérico do IBGE para MG que é 31.

Não deu certo, acorreu o mesmo resultado e a DLL modifica automaticamente o campo UF de 31 para SP, que é o padrão.

Modifiquei conforme sugestão

Código: Selecionar todos

[DFe]
SSLCryptLib=1
SSLHttpLib=3
SSLXmlSignLib=4
UF=31
TimeZone.Modo=0
TimeZone.Str=
URLPFX=
ArquivoPFX=f:\nfe\chave\dadadadada.PFX
DadosPFX=
Senha=IDYFQwRudkA=
NumeroSerie=
VerificarValidade=1

Após executar a método voltei no arquivo e estava assim.
UF=SP
A dll modificou a tag automaticamente.

Verifiquei o arquivo de retorno XML e fez a consulta pela UF de SP

Código: Selecionar todos

<?xml version="1.0" encoding="UTF-8"?>
-<retConsStatServ xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00">
<tpAmb>1</tpAmb>
<verAplic>SP_NFE_PL009_V4</verAplic>
<cStat>107</cStat>
<xMotivo>Serviço em Operação</xMotivo>
<cUF>35</cUF>
<dhRecbto>2026-01-24T23:06:32-03:00</dhRecbto>
<tMed>1</tMed>
</retConsStatServ>

Saudações,

Júlio.

[jelias]

Olá amigos,

Fiz uma pesquisa sobre a função DllCall para entender o máximo de detalhes, até agora não consegui resolver.
Fico sempre desconfiado que existe algum detalhe relacionado a variável oRetorno que durante o uso da função dllcall está causando algum erro, etc.

Código: Selecionar todos

O uso do comando DLLCall no xHarbour (ou a função DllCall() da hbpcode) é uma ferramenta poderosa para acessar APIs do Windows ou bibliotecas C externas. No entanto, o retorno de variáveis — especialmente quando se espera que a DLL modifique um valor passado por referência — é onde a maioria dos desenvolvedores encontra problemas.

Aqui estão os principais pontos de atenção e os problemas mais comuns:

1. Passagem por Referência vs. Valor
No xHarbour, se você precisa que a DLL altere o conteúdo de uma variável (o famoso "ponteiro" em C), você deve passá-la usando o operador @. Se esquecer disso, a DLL receberá apenas uma cópia do valor, e qualquer alteração feita por ela será perdida.

Problema: A variável continua com o valor original após a chamada.

Solução: DLLCall(hLib, DLL_OSAPI, "MinhaFuncao", @cVariavel)

2. Inicialização de Buffer (Strings)
Este é o erro "número 1". As DLLs em C não gerenciam a memória para o xHarbour. Se a DLL espera gravar uma string de 100 caracteres em um parâmetro, você precisa pré-alocar esse espaço no xHarbour.

O Erro: Passar uma string vazia "" ou curta. A DLL tentará escrever em um local de memória que não pertence à variável, resultando em um GPF (General Protection Fault) ou corrupção de memória.

Solução: Use Space(256) ou Replicate(Chr(0), 256) antes da chamada para criar um "balde" onde a DLL possa despejar os dados.

3. Incompatibilidade de Tipos de Dados
O xHarbour é fracamente tipado, enquanto as DLLs (geralmente em C/C++) são rigidamente tipadas.

Inteiros: Uma DLL pode esperar um LONG (32 bits) ou um LONGLONG (64 bits). Passar o tipo errado pode fazer com que a função leia bytes adjacentes da memória.

Ponteiros: Se a DLL retornar um ponteiro (um endereço de memória), o xHarbour verá apenas um número longo. Você precisará de funções auxiliares (como Peek()) para ler o conteúdo desse endereço.

4. Convenções de Chamada (Calling Conventions)
Existem duas principais: __stdcall (comum na API do Windows) e __cdecl (comum em bibliotecas C puras).

Problema: Se você usar a convenção errada, a pilha (stack) de memória não será limpa corretamente. O programa pode não travar imediatamente, mas apresentará comportamentos erráticos ou fechará do nada mais tarde.

Dica: Verifique se a sua versão do DLLCall permite especificar a convenção ou se você deve usar funções específicas como HB_DynCall().

[ANDRIL]

Em um projeto tentei usar a DLLCALL() NAO RETORNAVA NADA de dados. Tive que adaptar para usar a hb_DynCall(), assim deu certo.

#include "hbdyn.ch"

Era
Para abrir a dll hDLL := DllLoad( "SUA.DLL" )
Para fechar a dll DllUnload( hDLL )
Uso DllCall(hDLL,32,"ConfigLpt",nPorta,nTimeout)

Ficou
Para abrir a dll hDLL := hb_libLoad("SUA.DLL")
Para fechar a dll hb_libFree( hDLL )
Uso hb_DynCall({"ConfigLpt",hDLL, HB_DYN_CALLCONV_STDCALL },nPorta,nTimeout)

Quem sabe pode ser o seu problema.

[jelias]

Grato pela sua contribuição Andril.

A função hb_dyncall() é exclusiva do Harbour. Atualmente estou usando xHarbour 1.2.1.


Saudações,

Júlio.

[JoséQuintas]

Se está criando do zero, pesquisa a rotina existente pra (x)harbour, tem lá no acbr também pra download.
Tinha postado outras coisas aqui, mas apaguei, porque a mensagem do Andril já diz tudo.
Verifique se instalou as outras DLLs de SSL/TCP, lembrando que W98 não vém com isso padrão, não sei se pode ser o seu caso.