C / API / Harbour

Mensagem por **JoséQuintas** » 25 Mar 2016 20:22

Numa tentativa de alterar a GTWVG do Harbour 3.2, descobri uma coisa interessante:

aWindowRect := wvg_GetWindowRect( hWnd )

wapi_GetWindowRect( hWnd, aWindowRect )

Nos dois casos é retornado um array de 4 elementos com posição e tamanho da janela.
No primeiro caso, os elementos do array não aceitam Int()

Minha dedução é que os parâmetros no primeiro caso não são compatíveis com Harbour.

E ao aplicar isso na janela, lá vém o problema novamente:
Depende da função utilizada. Se é ou não compatível com Harbour, pra aceitar os parâmetros no mesmo formato.

Isso me fez pensar o seguinte:
- não basta conhecer a API do Windows, porque os parâmetros precisam ser no mesmo formato
- Às vezes a função pode não funcionar só por causa desse formato

Aí vém outras questões:

Teríamos que ter todas as funções da API no Harbour, compatíveis com Harbour?
Daria pra ter funções de conversão no Harbour, pra não ter que criar tudo que é API no Harbour?
Vamos sempre depender de alguém com conhecimento em C pra fazer alguma coisa?

E outras:
Se existisse tudo isso no Harbour, as LIBs GUI se limitariam a fonte PRG acessíveis ao usuário?
Se todas as LIBs GUI fossem PRG, daria pra usar tudo de todas em todas?
Seria essa uma unificação de todas GUI Windows?

Atualmente só quem conhece C é que pode construir/melhorar LIBs GUI.
Dessa forma, qualquer um poderia construir/melhorar uma LIB GUI.

É interessante... não sei exatamente o que pensar, a primeira impressão é de que poderia abrir muitas possibilidades.

A única certeza é que se o Viktor não tivesse criado mais funções de API na hbwin, eu não teria conseguido fazer o que fiz na GTWVG.
Eu teria feito a mesma coisa e não teria funcionado, por causa dessas diferenças de tipo de variável/conteúdo.

Mensagem por **Claudio Soto** » 04 Fev 2017 17:10

Es verdad José, existen demasiadas lib gráficas para Hb, el problema es que cada uno de los desarrolladores tenemos una visión diferente de como implementarla y ahí surgen las diferencias. Eso crea un enorme superposición de código y esfuerzo que al final termina confundiendo al usuario final que muchas veces no sabe por cuál optar ni como empezar. Si ha eso le sumamos una falta de una buena documentación y de buenos tutoriales es un caos total.

Creo que el gran error de Hb fue no implementar una lib GUI oficial desarrollado por los reponsables del proyecto, no en parecería con terceros como intentaron con qt y luego terminaron separando ambos proyectos y cada cual sigue su visión.

Estamos totalmente de acuerdo, la falta de padronizacion esta siendo el comienzo del fin de Hb. Pero también una lib gráfica tiene sus dificultades, como son todas dependientes del SO para crear y manejar la parte gráfica, es necesario que el usuario aprenda al menos lo básico de como se programa en forma nativa en dicho SO y cada SO es un mundo aparte.

El problema principal es siempre seguir el mismo padron de desarrollo, es decir o hacemos todo lo mas parecido al estilo hb o todo al estilo C, cada uno de estos estilos tiene sus ventajas y desventajas. Por ej. hacerlo al estilo C da mucha flexibilidad al programador, se minimizan los errores en el desarrollo de la lib pero requiere un conocimiento más profundo de como funciona la parte GUI a nivel del SO, al estilo Hb es exactamente lo contrario.

Un ej tonto pero que ocurre muy a menudo son el tema de las coordenadas, hb utiliza row y col, en C es al revés es x,y, entonces al desarrollar la rutina primero hay que decidir cuál formato usar y luego tener la precaución de no pasar los parámetros al revés.

Mensagem por **JoséQuintas** » 04 Fev 2017 19:20

Isso de row/col ou x/y uso na minha classe de PDF, e a GTWVG também usa em suas coordenadas.

No caso da minha classe pra PDF, tenho uma função que converte usada em toda classe.

Código: Selecionar todos

:ToPDFRowCol( a, b )

Na classe, basta usar sempre essa conversão e pronto.
O usuário pode escolher o estilo que quiser.

No caso da GTWVG ela usa positivo pra x/y ou negativo pra row/col.
O resultado na GTWVG foi muito interessante.
Um controle na linha 3 coluna 3 até linha 5 coluna 10.
Ao redimensionar a janela, o controle acaba sendo redimensionado automaticamente, sem precisar fazer nada.
Ao mover para a mesma coordenada de antes, a conversão acaba retornando valores recalculados e ele é ampliado/reduzido.
Isso não acontece se usar coordenadas x/y

Pelo que pude perceber na mistura minigui/gtwvg, o ponto chave da unificação seriam os controles serem reconhecidos, e a "navegação windows" entre controles.
Se não houver uma centralização dessa parte comum, cada LIB terá a sua, de forma diferente.

Não sei se dá pra usar o próprio esquema do Windows pra isso, e deixar cada controle independente.
Ou criar um esquema de mensagems no Harbour.