Divertido testar hmg exended

[JoséQuintas]

Só posso dizer que está divertido testar hmg extended.

Vamos ao roteiro:

Baixe minigui extended, do site do fornecedor
instale numa pasta

DENTRO DESSA PASTA E SUBPASTAS
- Apague todo Harbour
- Apague todos os 700 BATs
- Apague todas as LIBs
- Apague todos os HBPs

Baixe também minigui, oohg, pra poder olhar os fontes e corrigir problemas.
Cuidado nos testes, o Windows é alterado por ela, provavelmente bug na FindWindow.

Como tanta gente usa? não faco idéia.
Talvez o antigo BCC seja compatível com fontes antigos, e impeça problemas maiores

Mas é legal, visual legal.

Ia até mostrar o fonte, mas perdi.
Vou fazer de novo, porque tá muuuito interessante.
Simplificando: é meu menu de sempre, MEU FONTE DE SEMPRE, mas em hmg extended.
Por enquanto só restou a foto.
A maior parte do fonte do menu está naquele meu AllInOne pra GTWVG, é sério.

[JoséQuintas]

Meus testes são totalmente fora do tradicional, pelo menos pra HMG extended....
Não façam isso em casa, a menos que saibam o que estão fazendo

- Removi da minigui a errorsys, prefiro a minha
- Removi da minigui o console optional, deixei gtwvg
- Dá duplicidade no conteúdo nos CH, porque muita coisa já existe definida no Harbour

NÃO TENTEM COMPILAR MEUS FONTES. (ou tentem)
Modifiquei alguns arquivos da hmg pra isso.
Ainda ajustando tudo.

Estou usando meu AllInOne como base.

Alteração 1: módulo principal:

Código: Selecionar todos

ANNOUNCE HB_GTSYS

PROCEDURE Main

   HarbourInit()
   hb_ThreadStart( { || MainMenu( .F. ) } )
   menuhmg()
   hb_ThreadWaitForAll()
   RETURN

PROCEDURE GT_SYS
   REQUEST HB_GT_WVG_DEFAULT
   RETURN

Módulo adicionado, usando hmg:

Código: Selecionar todos

#include "hmg.ch"

FUNCTION menuhmg()

   SET MENUSTYLE EXTENDED
   DEFINE WINDOW Form_1 ;
          AT 0,0 ;
          WIDTH 640 HEIGHT 480 ;
          TITLE 'Dynamic Menu Demo' ;
          ICON "MAIN.ICO" ;
          ; // NOTIFYICON "STOP.ICO" ;
          MAIN ;
          FONT 'Arial' SIZE 10
          BuildMenuHmg()
          DEFINE TOOLBAR ToolBar_1 BUTTONSIZE 45,40 /*IMAGESIZE 22,22*/ FONT 'Arial' SIZE 8  FLAT
                 //BUTTON Button_1   CAPTION 'Undo'   PICTURE 'button4.bmp'   ACTION MsgInfo('Click! 1')
                 //BUTTON Button_2   CAPTION 'Save'   PICTURE 'button5.bmp'                                WHOLEDROPDOWN
                 //BUTTON Button_3   CAPTION 'Close'  PICTURE 'button6.bmp'   ACTION MsgInfo('Click! 3')   DROPDOWN
          END TOOLBAR
   END WINDOW
   CENTER WINDOW Form_1
   ACTIVATE WINDOW Form_1

   RETURN NIL

FUNCTION BuildMenuHmg()

   LOCAL acMenu

   DEFINE MAIN MENU OF Form_1
   acMenu := MenUCria()
   BuildOptionsMenu( acMenu )
   END MENU

   RETURN NIL

FUNCTION BuildOptionsMenu( acMenu )

   LOCAL nCont

   FOR nCont = 1 TO Len( acMenu )
      IF Len( acMenu[ nCont, 2 ] ) == 0
         //m_Prog := acMenu[ nCont, 3 ]
         ITEM acMenu[ nCont, 1 ] ACTION acMenu[ nCont, 3 ]
      ELSE
         POPUP acMenu[ nCont, 1 ]
         BuildOptionsMenu( acMenu[ nCont, 2 ] )
         END POPUP
      ENDIF
   NEXT

   RETURN NIL

Em execução, tudo junto e misturado.

Ainda pra resolver:
A HMG Extended teima em fechar o aplicativo quando fecha a tela main.
Pra ela parece que não existe mais nada além dela mesma e sua janela main....
Fecha até as outras threads.

Nota:
O menu é um array. Cada janela usa esse array pra criar o menu de acordo com o que precisa.
Tem estilo console, estilo Windows básico, estilo minigui extended.

[JoséQuintas]

Complemento:
Pra mim a HMG Extended deveria respeitar esta parte, tem uma linha após o formulário/janela:

Código: Selecionar todos

   menuhmg()
   hb_ThreadWaitForAll()
   RETURN

[JoséQuintas]

Também não adiantou dar uma janela nova pra ela.

Código: Selecionar todos

FUNCTION menuhmg()
   hb_gtReLoad( "WVG" )

[JoséQuintas]

Também não adianta dar uma thread inteira pra ela.
Não sei aonde ela cria variáveis públicas na thread principal, que não ficam visíveis na thread.

Código: Selecionar todos

PROCEDURE Main

   HarbourInit()
   hb_ThreadStart( { || MainMenu( .F. ) } )
   hb_ThreadStart( { || menuhmg() } )
   hb_ThreadWaitForAll()
   RETURN

Provavelmente alguma rotina C ou algo assim, que cria variável pública antes de Main() ou embutido, sei lá.

Pra quem não sabia disso, a minigui se utiliza de uma variável pública pros seus controles.
Não dá pra perceber nos fontes, por causa do I_VAR.CH
Abaixo conteúdo parcial.

Código: Selecionar todos

#ifndef __SYSDATA__
  #define __SYSDATA__
  MEMVAR _HMG_SYSDATA
#endif

#define _HMG_SYSDATA_SIZE			445

#xtranslate _HMG_ErrorLogFile			=> _HMG_SYSDATA\[1\]
#xtranslate _HMG_CreateErrorlog			=> _HMG_SYSDATA\[2\]

#xtranslate _HMG_ActiveIniFile			=> _HMG_SYSDATA\[3\]
#xtranslate _HMG_ActiveTreeValue		=> _HMG_SYSDATA\[4\]
#xtranslate _HMG_ActiveTreeIndex		=> _HMG_SYSDATA\[5\]
#xtranslate _HMG_ActiveTreeHandle		=> _HMG_SYSDATA\[6\]
#xtranslate _HMG_NodeHandle			=> _HMG_SYSDATA\[7\]
#xtranslate _HMG_NodeIndex			=> _HMG_SYSDATA\[8\]
#xtranslate _HMG_aTreeMap			=> _HMG_SYSDATA\[9\]
#xtranslate _HMG_aTreeIdMap			=> _HMG_SYSDATA\[10\]
#xtranslate _HMG_ActiveTreeItemIds		=> _HMG_SYSDATA\[11\]
#xtranslate _HMG_ActiveDragImageHandle		=> _HMG_SYSDATA\[12\]

[JoséQuintas]

Uma parte deu certo, mas outra não.
Como não costumo usar, tem a INIT, onde é criada a variável pública.
INIT é executada automaticamente pelo Harbour.

Alterei a Init() pra hmgInit(), e chamei no módulo minigui.

Código: Selecionar todos

FUNCTION menuhmg()

   MiniguiInit()

Pronto, minigui funcionando em thread isolada.

Mas.... ao fechar janela main, fecha tudo.

Resolvido pra iniciar em outra thread, mas ainda não resolvido pra fechar tudo.

[JoséQuintas]

Último teste de hoje disso tudo:

Código: Selecionar todos

PROCEDURE Main

   hb_gtReload( "WVG" )
   HarbourInit()
   hb_ThreadStart( { || MainMenu( .F. ) } )
   hb_ThreadStart( { || menuhmg() } )
   //hb_ThreadWaitForAll()
   RETURN

Ao retirar a espera de multithread, tudo se fecha.
Ao que parece, o módulo principal funciona corretamente, e o problema está na hora que fecha a janela Main() da minigui.
Isso confirma que a minigui está em uma thread secundária, não deveria fechar todo o aplicativo.

Na GTWVG, até mesmo um QUIT fecha apenas a thread.

[Claudio Soto]

HMG se cierra al cerrar la ventana main porque emula la filosofia de programar en windiows con C, donde existe una ventana principal y las demas son ventanas hijas, aunque en HMG en realidad estan implementadas como ventanas hermanas y no hijas pues asi es mas sencillo de manejar con harbour. Los thread son eventos hijos de los processos, y al cerrar main esta cierra el proceso y por lo tanto cierra todos los theread.

Con un poco de conocimiento de como se programa en C para windows es posible alterar el codigo y evitar que al cerrar main cierre el processo, para eso se debe llevar un contador de las ventanas activadas y cuando este llegue a cero cerrar el lazo de mensajes de windows, de lo contrario la app queda travada en un lazo infinito.

[JoséQuintas]

Não sei se o mesmo conceito de janelas poderia ser aplicado às threads.
Uma thread conhecer todas as threads que partiram dela.
Se isto for possivel, a Main() fecharia todas as threads abaixo dela e ela mesma.
Desta forma, a thread "pai" continuaria seu processo.

Se isto for possivel, pode trazer vantagens até mesmo pra própria minigui.
Aliás... vou fazer outro teste agora que me veio à cabeça: mais de uma janela main da hmg.

[JoséQuintas]

Qual a alternativa para uma Main em minigui sem janela visível?

[JoséQuintas]

Mais um teste.
Só curiosidade, porque não gosto de variável pública.

Eliminei a variável pública.

Em h_init.prg:

Código: Selecionar todos

STATIC _HMG_SYSTEM
FUNCTION _HmgSys() ; RETURN _HMG_SYSTEM

PROCEDURE Init
...
   _HMG_SYSTEM := Array( _HMG_SYSDATA_SIZE )

Em i_var.ch

Código: Selecionar todos

#define _HMG_SYSDATA              _HmgSys()
#xtranslate _HMG_ErrorLogFile			=> _HMG_SYSDATA\[1\]
#xtranslate _HMG_CreateErrorlog			=> _HMG_SYSDATA\[2\]

O que era a variável pública HMG_SYSDATA[ 2 ]
Agora é uma função _HmgSys()[ 2 ]
Fica disponível em todas as threads, e se for criar por thread, é só usar THEAD STATIC

Como eu disse, alterei só por curiosidade.
Teste comum todo mundo já faz, então vamos aos testes não comuns... rs

Não mexam na minigui de voces. Isto é só um teste meu.
Não faço a menor idéia se alterar isso vai trazer alguma vantagem, ou algum problema.
É só parte dos meus testes com multithread.

Apenas compartilhando meus testes, assim já economiza testes de outras pessoas que estejam pensando em fazer a mesma coisa.

[Claudio Soto]

José, las ventanas, los thread y los procesos son conceptos diferentes. Las ventanas y los thread no tienen ningún tipo de relación son dos cosas totalmente diferentes. No existe ninguna ventaja computacional en asociar una ventana o cualquier otro componente GUI a un thread. La única ventaja de usar thread es cuando se le asigna una tarea que consume mucho tiempo para que se realice en segundo plano y libere CPU, ej cargar en memoria un archivo muy grande, como ya puse en otro post un theread es una función común y corriente que se ejecuta en simultáneo con otras funciones en vez de ser ejecutadas en forma secuencial como las funciones normales. Por ejemplo si a un thread se lo bloquea en forma inadecuada para acceder a una variable se pueden transformar los thread en funciones secuenciales. Por ejemplo.

void * thread1()
{
threadMutexLock
...
threadMutexUnlock
return ptr;
}

Este código transforma al thread en una función común y corriente, porque el threadlock suspende la ejecución de todos los thread hasta que se desbloquea con Unlock, y como todo el cuerpo de la función se encuentra entre los bloqueos, mientras no se termine de ejecutar la funcion completa no se ejecuta otro thread y de esta manera es igual a llamar funciones en forma secuencial.

[Claudio Soto]

Windows es un SO operativo multitarea, es decir que puede procesar y ejecutar los eventos de varias ventanas a la vez, entonces por ejemplo usar dos thread para que creen y manejen los eventos de una ventana cada uno o cualquier otro componente GUI es una ilusión, nunca funcionan en multithread porque crear una ventana con un thread o una función secuencial es lo mismo porque una vez creados la funcion ya no es más de utilidad, porque todos los eventos de los componentes GUI son manejados a traves del sistema de cola de mensajes de Windows y no a través de las funciones, esto es lo que permite que Windows sea multitarea. La confusión surge talvez porque HMG trato de emular la programación secuencial de DOS (clipper) y eliminar a lo mínimo para el programador la complejidad de la programación por eventos (mensajes) de Windows.
En la programación en DOS el programa llama al SO, en Windows es al revez, el SO llama la app mediante mensajes, un ejemplo típico es que en Windows no existen los while con Inkey esperando a que el usuario presione una tecla como en DOS, en Windows el SO siempre le informa a la app cuando y en que ventana una tecla es presionada, y depende de la app si procesa o no ese msg.

[JoséQuintas]

La confusión surge talvez porque HMG trato de emular la programación secuencial de DOS (clipper) y eliminar a lo mínimo para el programador la complejidad de la programación por eventos (mensajes) de Windows.

Janelas, mensagens do Windows....

Criação de controles/janelas na HMG
Linguagem C chamando a API do Windows

Código: Selecionar todos

   hButton = CreateWindowEx ( 0, WC_BUTTON /*_TEXT("Button")*/ ,
                           HMG_parc(2),
                           Style ,
                           hb_parni(4) ,
                           hb_parni(5) ,
                           hb_parni(6) ,
                           hb_parni(7) ,
                           hwnd ,
                           (HMENU) HMG_parnl(3) ,
                           GetModuleHandle(NULL) ,
                           NULL ) ;

Criação de controles/janelas na GTWVG
PRG, que chama a API do Windows, através de uma função em C intermediária

Código: Selecionar todos

   hWnd := wapi_CreateWindowEx( ;
      ::exStyle, ;
      ::className(), ;
      "", ;                              /* window name */
      ::style, ;
      aPosSz[ 1 ], aPosSz[ 2 ], ;
      aPosSz[ 3 ], aPosSz[ 4 ], ;
      ::oParent:hWnd, ;
      ::nID, ;                           /* hMenu       */
      NIL, ;                             /* hInstance   */
      NIL )                              /* lParam      */

Mensagens do Windows pra Progressbar da HMG:

Código: Selecionar todos

HB_FUNC ( SETPROGRESSBARRANGE )
{
	SendMessage( (HWND) HMG_parnl (1), PBM_SETRANGE,0, (LPARAM) MAKELONG(hb_parni(2),hb_parni(3)) );   // add (LPARAM)
}
HB_FUNC ( SETPROGRESSBARMARQUEE )
{  
   HWND hWnd  = (HWND) HMG_parnl (1);
   BOOL OnOff = (BOOL) hb_parl (2);
   LONG Updated_milliseconds = (LONG) hb_parnl (3);
   LONG_PTR style = GetWindowLongPtr (hWnd, GWL_STYLE);
   if (OnOff == TRUE)
   {  SetWindowLongPtr (hWnd, GWL_STYLE, style | PBS_MARQUEE);
      SendMessage (hWnd, PBM_SETMARQUEE, (WPARAM) OnOff, (LPARAM) Updated_milliseconds);
   }
   else if ((style & PBS_MARQUEE) == PBS_MARQUEE)
   {   // style = style - PBS_MARQUEE;
       style = style & (~ PBS_MARQUEE);
       SetWindowLongPtr (hWnd, GWL_STYLE, style);
   }
}

Mensagens do Windows pra Progressbar da GTWVG

Código: Selecionar todos

METHOD WvgProgressBar:SetValue( nValue, nRangeMin, nRangeMax, nSpeed )

   IF HB_ISNUMERIC( nRangeMin ) .AND. HB_ISNUMERIC( nRangeMax ) .AND. ! ::lMarquee
      ::nRangeMin := nRangeMin
      ::nRangeMax := nRangeMax
      ::sendMessage( PBM_SETRANGE, 0, WIN_MAKELONG( ::nRangeMin, ::nRangeMax ) )
   ENDIF
   IF HB_ISNUMERIC( nValue ) .AND. ! ::lMarquee
      ::sendMessage( PBM_SETPOS, nValue, 0 )
      ::nValue := nValue
   ENDIF
   IF HB_ISNUMERIC( nSpeed ) .AND. ::lMarquee
      ::sendMessage( PBM_SETMARQUEE, 1, nSpeed )
      ::nSpeed := nSpeed
   ENDIF

   RETURN ::sendMessage( PBM_GETPOS, 0, 0 )

Dúvidas:
1) Como a HMG não consegue?
2) Como a GTWVG consegue?

[Claudio Soto]

La respuesta es sencilla, primero HMG nació cuando Hb ni soñaba con lo que era programacion GUI, segundo las gt de Hb fueron desarrolladas para emular el modo consola con algo de presentación gráfica pero sus capacidades son limitadas debido a su propia estructura interna, tal es así que creo que su desarrollo fue abandonado. Y en tercer lugar y más importante cualquiera de las lib GUI para Hb (HMG, Hwg, oohg,fivewin, etc) fueron diseñadas de acuerdo a como trabaja Windows y no como trabajo Hb, y por lo tanto cualquier cosa que se pueda hacer en C puro para Windows se puede implementar sin mucho esfuerzo con estas lib GUI. El potencial de las gt gráficas es muy limitado en comparación con las lib GUI tradicionales.