PC Toledo

Seguindo o fonte: a mensagem vai ser essa entre as duas linhas seguintes
XmlDSig:CreateKeyFromCSP() me parece que é criar uma cópia da chave de assinatura
E ela depende do conteúdo de oCapicomStore.

oCapicomStore é criada na chamada AssinaLoadCertificado( ... @oCapicomStore )
Trata-se de pegar o certificado.
E _CAPICOM_STORE_OPEN_MAXIMUM_ALLOWED, deve ser com o nível mais alto de segurança disponível.
Num nível menor, até acessa o certificado, mas pode não conseguir assinar.

Pode ter a ver com a forma de instalar o certificado, ou algum requisito adicional pra instalação.
Coisa que começou a ficar mais frequente de uns tempos pra cá.

Trabalho com NFE desde 2008, quase 10 anos já.
Vi isso acontecer com 2 certificados.
Não sei se depende da "fabricante" do certificado.

Ok, Valeu mesmo, deu pra entender como funciona, vou tentar fazer um teste!

O erro está na função win_OleCreateOject do harbour que dar este tipo de erro, quando testo a mesma função com xharbour ( xhb_CreateObject ) consigo assinar, validar, enviar e receber o retorno protocolo de entrega do web service, no entanto eu queria fazer funcionar tambem com harbou pois estou convertendo todos os sistema para harbour

esta função do xharbour está em w32ole.prg , no entanto quando eu troco a função xhb_CreateObject para win_OleCreateOject do harbour gera o erro aqui signedKey := xmldsig:sign( dsigKey, _SIG_KEYINFO )

O erro está na função win_OleCreateOject do harbour que dar este tipo de erro

Aí que está
win_OleCreateObject() é da hbwin, biblioteca de funções específicas do WINDOWS.
O problema acontece ao misturar no mesmo EXE coisas do Harbour e do xHarbour.
Por isso o VIktor já avisou que a biblioteca do xHarbour poderá ser removida, porque não é compatível, ninguém está atualizando.

Lembro de um problema com outro usuário, que acontecia depois de usar automação Word ou Excel.
Justamente porque nessa automação usava de outro jeito, e uma interferia com a outra.

À primeira vista a questão é simples: ou trabalha como Harbour ou trabalha como xHarbour. Trabalhar dos dois jeitos não dá.

E infelizmente, a coisa é pior que essa: o Harbour 3.2 também está desatualizado. O manifest dele não foi atualizado pra Windows 10 porque tem funções que não se sabe se vão funcionar no Windows 10. O manifest atual faz ele trabalhar em modo de compatibilidade com Windows anteriores.

Eu uso apenas o que vém pronto nos fontes do Harbour 3.4, e NÃO uso compatibilidade xHarbour. (xhb.hbc NÃO).

Até um tempo atrás eu só usava MSVC, mas parei de usar quando numa versão mais recente do Windows 10 acaba sendo necessário ficar instalando run-time de MSVC.

A partir daí, é com o que cada um decidir.

Onde eu consigo uma versao do harbour 3.4 compilado para bcc7

Não consegue.
BCC não é mais suportado no 3.4.

Tem que ser compativel com fivewin

· A Windows Resource Editor is HIGHLY recommended. We normally use Borland’s Resource WorkShop. We have also successfully tested Microsoft AppStudio resource editor. These tools come with Borland’s C/C++ compiler or Microsoft Visual C++ compiler.
See the following:
· It is highly recommended that you acquire Borland’s Turbo C++ for Windows or Borland’s C++ 3.1 or Borland’s C++ 4.0 or above.
We normally use Borland C++ 3.1. And all the C code included in FiveWin has been developed using Borland C/C++ compiler.
Also, Microsoft Visual C++ is a highly recommended tool to acquire. Also we have tested with Symantec C++.

Visual C++ é opção mesmo?

Mas lembro de ter visto em algum lugar sobre mingw, até com comentário do Viktor sobre finalmente ter.

Infelizmente a informação da página é velha, não sei se vale.

Software requirements:
· CA-Clipper 5.01, CA-Clipper 5.2 or CA-Clipper 5.3.
...

Nem atualizar o site, ele atualiza.

Realmente muito mal documentado.
Vindo do readme.

FWH - FiveWin for Harbour
* Borland BCC 5.5 version: fiveh.lib, fivehc.lib
* Microsoft Visual C++ version: fivehm.lib, fivehcm.lib

FWHX - FiveWin for xHarbour
* Borland BCC 5.5 version: fivehx.lib, fivehc.lib
* Microsoft Visual C++ version: fivehmx.lib, fivehcm.lib

FWH64 - FiveWin 64 for Harbour/xHarbour 64 bits
* Harbour and Microsoft C 64 version: fiveh64.lib, fivehc64.lib
* xHarbour and Microsoft C 64 version: fiveh64x.lib, fivehc64.lib

Sabe-se a versão exata do Borland C, mas nada sobre Visual C.
É um convite pra não usar, porque teria que testar cada uma das versões do Visual C pra descobrir qual é.

Se fosse algo grátis dava até pra entender....

E se os fontes estiverem igual à documentação, não é à toa que acabam usando Borland C ultrapassado....

Primeiro contato:

Baixei o demo.
Primeira compilação da pasta winapi:

c -include..\..\fivewin
netapi32.prg:94: warning W0003 Variable 'CBUFFER' declared but not used in function '20:NETSERIALNUMBER'

Variável inútil no fonte, que não serve pra nada.... rs
Não é fonte de teste, ou sei lá, está em \fivewin\source\winapi

Pasta resolvida, foi só apagar a declaração da variável inútil.
fui pra geral.

classes\*.prg
classes\*.c
function\*.prg
function\*.c
winapi\*.prg
winapi\*.c
-I..\include

classes\activex.prg:31: warning W0004 Codeblock parameter 'HDC' declared but not used in function 'TACTIVEX'
classes\activex.prg:43: warning W0004 Codeblock parameter 'NFLAGS' declared but not used in function 'TACTIVEX'
classes\activex.prg:86: warning W0001 Method <Do( cMethodName, uParam1, uParam2, uParam3, uParam4 )> not declared or declaration mismatch in class <TActiveX>
100
classes\activex.prg:129: warning W0001 Ambiguous reference 'SUPER'
classes\activex.prg:138: warning W0001 Method <OnEvent( nEvent, aParams, pParams )> not declared or declaration mismatch in class <TActiveX>

Fontes também mal cuidados.
Mais variáveis inúteis, e métodos declarados de um jeito mas criados de outro.

Não entendo o que seriam \fivewin\source\classes, \fivewin\source\function \fivewin\source\winapi, se é realmente fonte da fivewin ou só teste.

Sobre o primeiro erro:

METHOD EraseBkGnd( hDC ) INLINE 1

Recebe o parâmetro hDC e não usa pra nada, e nem faz nada, apenas retorna 1.
Por isso o Harbour 3.4, em compilação -w3 -es2 acusou erro (esse é meu default de compilação)

É por isso que muitos não gostam do Harbour 3.4... mostra erros.... rs

Tudo bem, dá pra desativar --w3 -es2, mas não sei se para o compilador C vai resolver, vamos ver o que dá...

classes\ddeserv.prg:11: error F0029 Can't open #include file 'DdeFV.ch'
hbmk2 [test]: Error: Running Harbour compiler (built-in). 1

d:\temp\fwh\source>dir ..\ddefv.ch /s
O volume na unidade D é TRABALHO
O Número de Série do Volume é 864A-700A
Arquivo não encontrado

Está dando falta de um CH que não existe.
Com -w0 -es0, não checa erros de #define.

Descobri pra que serve BYNAME, a invenção doida da fivewin:

METHOD New( cName, cType, nLen, nDec ) CLASS TField
cName := Upper( cName )
cType := Upper( cType )

do case
case cType == 'L'
nLen:= 1
nDec:= 0

case cType == 'D'
nLen:= 8
nDec:= 0

case cType == 'M'
nLen:= 10
nDec:= 0
endcase

BYNAME cName DEFAULT ""
BYNAME cType DEFAULT "C"
BYNAME nLen DEFAULT 0
BYNAME nDec DEFAULT 0

return nil

Ao que tudo indica, isso seria equivalente a
hb_Default( @cName, "" )
Ou DEFAULT cName TO ""

Só que em qualquer parte do fonte, não no início como é costume.

Sei lá... esse tipo de fonte assusta.
Parece falta de profissionalismo.
Pra melhor das LIBs gráficas, e mais usada de todas, e COMERCIAL, não esperava coisas assim.

Mas pode ser o Harbour 3.4 que acostumou mal.... rs
Se não existissem os recursos, nem ficaria saendo.

Ah é faltou dizer: é justamente nessas linhas que dá erro.
Tem isso em muitos fontes.

É o TRIAL, pra quem está interessado em usar/comprar, então me interessei um pouquinho e estou tentando chegar a algum lugar.

O último sobre o assunto: chegou na parte em C.

In file included from d:/temp/fwh/source/winapi/wndupdat.c:3:0:
d:/temp/fwh/include/ClipApi.h:465:9: error: conflicting types for 'strcmp'
BOOL strcmp( LPSTR szString1, LPSTR szString2 );
^~~~~~
In file included from d:/harbour/comp/mingw/mingw64/x86_64-w64-mingw32/include/guiddef.h:148:0,
from d:/harbour/comp/mingw/mingw64/x86_64-w64-mingw32/include/winnt.h:628,
from d:/harbour/comp/mingw/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
from d:/harbour/comp/mingw/mingw64/x86_64-w64-mingw32/include/windef.h:8,
from d:/harbour/comp/mingw/mingw64/x86_64-w64-mingw32/include/Windows.h:69,
from d:/temp/fwh/source/winapi/wndupdat.c:2:
d:/harbour/comp/mingw/mingw64/x86_64-w64-mingw32/include/string.h:63:15: note: previous declaration of 'strcmp' was here
int __cdecl strcmp(const char *_Str1,const char *_Str2);

Pelo que entendo, usando mingw, acusa duas funções com mesmo nome mas parâmetros diferentes.
Se não me engano o BORLAND C linquedita coisa duplicada normalmente, sem fazer checagem.
Qual das duas é a correta.... sei lá...
As duas fazem parte dos arquivos #include do mingw.

Isto serve pra mostrar qual a diferença entre o antigo Borland C e os compiladores C mais atuais.
Nem sempre se trata de usar funções mais modernas ou incompatíveis, mas de facilidades para ajudar o programador a evitar erros.

Não precisa alterar o Harbour pra aceitar fonte errado, precisa acertar o fonte da LIB.
Ficaria até melhor para o Borland C.... rs