HBWin

[MSDN]

Pessoal, as vezes a gente se bate para achar solução, vê um código fonte com um comando ou função que nunca viu ou não entende os parâmetros, e isso ocorreu comigo hoje, porém, buscando pelo Google, achei esse link que mostra de forma bem clara o que temos na HBWin.

https://github.com/Petewg/harbour-core/wiki/HBWIN

[Claudio Soto]

Muy buena documentación, lo único que hay que tener cuidado si se mezclan hbwin con alguna hmg,hwg,etcétera es que si no me equivoco hbwin trabaja con punteros y no con numeros enteros, por ejemplo:
wapi_GetActiveWindow() ➜ hWnd
En hbwin hWnd es un puntero y en las lib gráficas es un entero, por lo tanto es necesario convertir los datos antes de pasarlos a otras lib. Esto es muy sencillo hacerlo con una función en C:
viod * ptr = hb_ptr (1);
hb_retnl ((INT) ptr);

Y la inversa:
INT p = hb_parnl (1);
hb_retptr ((void *) p);


Esto es lo que hacen estas funciones
win_N2P(<nNum>) ➜ pPointer

win_P2N(<pPointer>) ➜ nNum

[depaula.jau]

Nossa!

Eu entendi sobre os ponteiros. Você pode chamar duas libs com os mesmos ponteiros correto ?

Fui anexando as libs ao longo do tempo e nem me preocupei com isso

Exemplo:
CALL C:\MiniGUI\BATCH\compile.bat ModuloPrincipal /m /l iphlpapi /l hbtip /l ws2_32 /l harupdf /l hmg_hpdf /l libhpdf /l hbhpdf /l libhpdf /l hbzebra /l libpng /l zlib /l BosTaurus /l hbwin %1 %2 %3 %4 %5 %6 %7 %8 %9

Claudio Soto, vc pode detalhar melhor como aplicar essa funcão C nas aplicações ?

Marcelo de Paula

[JoséQuintas]

Isso de usar inteiro foi removido do Harbour 3.4 por ser considerado perigoso, mas não sei detalhes técnicos sobre isso.

Me parece que o ponteiro é equivalente a variável passada por referência.

[JoséQuintas]

do link que foi postado.

[JoséQuintas]

O commit.
Parece que ficou na compatibilidade com XHarbour....

[Claudio Soto]

Nossa!

Eu entendi sobre os ponteiros. Você pode chamar duas libs com os mesmos ponteiros correto ?

Fui anexando as libs ao longo do tempo e nem me preocupei com isso

Exemplo:
CALL C:\MiniGUI\BATCH\compile.bat ModuloPrincipal /m /l iphlpapi /l hbtip /l ws2_32 /l harupdf /l hmg_hpdf /l libhpdf /l hbhpdf /l libhpdf /l hbzebra /l libpng /l zlib /l BosTaurus /l hbwin %1 %2 %3 %4 %5 %6 %7 %8 %9

Claudio Soto, vc pode detalhar melhor como aplicar essa funcão C nas aplicações ?

Marcelo de Paula

Marcelo, por ej. usando

wapi_CreateDC([<cDriver>], [<cDeviceName>], [<cOUtput>], <pDeviceMode>) ➜ hDC

la función retorna un puntero a un handle del contexto del dispositivo en cuestión, para poder usar ese puntero al DC con HMG primero hay que transformarlo en un número,

n_hDC = win_P2N( p_hDC )

ahora la dirección de memoria al cual apunta el puntero p_hDC se transformó en un número entero n_hDC que puede ser usado en cualquier función de HMG que utilice un hDC (ej. Bos Taurus )

La inversa también es válida, se puede usar cualquier handle de HMG que son direcciones de memoria almacenada en un numero entero con hbWin

p_hDC = win_N2P( n_hDC )

[Claudio Soto]

viod * ptr = hb_ptr (1);
hb_retnl ((INT) ptr);

Y la inversa:
INT p = hb_parnl (1);
hb_retptr ((void *) p);

Acá está el código en C de Hb de las funciones win_N2P y win_P2N, hacen lo mismo que el código en C que postee anteriormente

HB_FUNC( WIN_N2P )
{
   hb_retptr( HB_ISPOINTER( 1 ) ? hb_parptr( 1 ) : ( void * ) ( HB_PTRDIFF ) hb_parnint( 1 ) );
}

HB_FUNC( WIN_P2N )
{
   hb_retnint( HB_ISNUM( 1 ) ? hb_parnint( 1 ) : ( HB_PTRDIFF ) hb_parptr( 1 ) );
}

[Claudio Soto]

Isso de usar inteiro foi removido do Harbour 3.4 por ser considerado perigoso, mas não sei detalhes técnicos sobre isso.

Me parece que o ponteiro é equivalente a variável passada por referência.

Los punteros son un tipo de variable especial que apuntan a una dirección de memoria determinada.

En el comentario del código en Hb dice que es inseguro porque al usar enteros se puede pasar un número ( dirección de memoria ) arbitrario a una función y trabar la maquina, lo cual es cierto si uno es descuidado y le asigna cualquier valor. Internamente Windows utiliza enteros para manejar el valor de los handles.
Pero el mayor peligro en usar enteros en vez de punteros es el incremento y decremento en las direcciones de memoria, porque los punteros tienen un tipo (ej. int, char, double, una estructura, una función, etc) y el tipo le da el offset del desplazamiento en la aritmética de punteros, ej. un int tiene 32 bits (4 bytes ) y un puntero a un int tendrá un desplazamiento de 4 bytes, por ej si p apunta a la dirección 100, entonces
p + 1 apuntará a la dirección 104.

En cambio si trabajamos con enteros en vez de punteros la dirección p+1 será siempre 101, por lo tanto hay que tener mucho cuidado, lo correcto sería:
p + size * incremento
Donde size es el tamaño en bytes del tipo de puntero, ej. 8 bytes en un double, 1 en char, 4 en los handles de Windows, etc.

[JoséQuintas]

Entendi.
Ponteiro é sempre ponteiro, uma posição de memória.
Int seria uma representação numérica pra chegar ao ponteiro.
No C, o Int é um binário, que dependendo do tipo de Int pode ter tamanho diferente e representar número diferente.
Por fim, as rotinas C tem conversão de tipo numérico de/para C/Harbour, o que pode ter resultado diferente, dependendo de como foi escrita a função, e isso é a parte perigosa.

O erro de posição de memória no Windows é aquele famoso GPF/Tela Azul... porque um programa pode estar tentando usar uma porção de memória que não está mais disponível.

[JoséQuintas]

Acrescentando... não exatamente na conversão.
É justamente a parte que mencionei sobre preferir o Harbour 3.4, e sobre alterações que pude fazer na GTWVG.

Ao pegar tamanho de janela e dividir por 2, na GTWVG do Harbour 3.2, o resultado não era o esperado, por falta de conversão.
No Harbour 3.2 o retorno é binário, e binário dividido por 2 não dá o mesmo resultado, porque a divisão teria que também ser em binário.
No Harbour 3.4 existe a conversão da API Windows, e o retorno é em "formato Harbour".

Na mistura de rotinas entre LIBs e/ou DLLs, essa conversão precisa ser equivalente: pode não funcionar, gerar retorno errado, ou até gerar o GPF.

É tudo simples, e complicado ao mesmo tempo.... rs
Eu só acho que, se estamos trabalhando com Harbour, o melhor seria o máximo de ida e volta no formato do Harbour, deixar toda conversão pra parte C.

[depaula.jau]

Na mistura de rotinas entre LIBs e/ou DLLs, essa conversão precisa ser equivalente: pode não funcionar, gerar retorno errado, ou até gerar o GPF.

É justamente isso que estava tentando entender, essa mistura de LIBs que são incorporadas as aplicações.

[JoséQuintas]

Pois é, o armazenamento é feito em BYTE, 1 byte = 8 bits.
Com 8 bits dá pra representar de 0 até 255 - igual a tabela ASCII de caracteres.
Cada tipo numérico tem um armazenamento diferente.
Justamente pra passar entre C e Harbour, ou até mesmo entre C e C, precisa ser o mesmo formato.

Uma coisa antiga que sabemos do C, é que ele faz o que o programador manda..
Se pedir pra somar A + 1, o resultado pode ser B. ( 65 + 1 , o Asc( "A" ) + 1.
E se pedir pra somar 1 + 1 ?
Depende:
Se somar binário 1 + binário 1, dá binário 2.
Se somar Asc("1") + Asc("1"), o resultado é 98.
Essa seria a diferença, no caso de conversão diferente. De 2 pra 98, a diferença é grande.....

E voltamos novamente ao que comentei:
Seria mais prático o nosso resultado conhecido em Harbour, e não em binário.
Deixar essa parte dentro do fonte C, sem ter que se preocupar com isso no fonte PRG.
Quanto mais coisa em C usando formato C... só mais coisa em formato C pra resolver.
Se funções básicas em C trabalham em formato Harbour... o resto pode ser PRG.

Seria a diferença entre nós e o Harbour trabalharmos sozinhos, ou de sempre depender de alguém pra qualquer alteração simples.

Voltando ao caso que mencionei da GTWVG: precisar de alguém pra simples operação de dividir o tamanho por 2.
Era só aprender C? nesse caso não... foi só ter a rotina de C compatível com Harbour....
Lembrando que tanto a rotina de obter valores, ou de usar valores ficaram compatíveis - trata-se sempre do conjunto e não de uma função isolada.
No caso de uma LIB, pode precisar reformular a LIB inteira, ou boa parte dela.

[JoséQuintas]

Já pensou?
Todas as LIBs no mesmo formato, e com fonte PRG?
Seria juntar todas as LIBs gráficas !
Recursos de todas pra todas !

Impossível?
Talvez sim, talvez não.... o Harbour seria o ponto comum.... mas não é... porque tem o XHarbour também....

[syslink]

Talvez sim, talvez não.... o Harbour seria o ponto comum.... mas não é... porque tem o XHarbour também....

esse é o grande problema de linguagem híbrida ou opensource.
Todos querem meter sua colher e fazer uma variação e criar outras variações. Bom, mesmo é todos os autores das libs se humilharem e incorporarem em todas as mesmas funções de todas. Como é o caso da hmg3 que já tem na contribs a wvg. vamos lutar para essa padronização antes que o harbour se extinga de uma vez por todas e nosso clipper realmente aposente.