Me lembrou que não testei todas as possibilidades, tinha faltado GTWVT e GTWVW.
- Código:
PROCEDURE Main
//__oohg_init()
//hb_ThreadStart( { || Tstrmchart() } )
//hb_ThreadStart( { || Tstgtwvg() } )
//hb_ThreadStart( { || TestHWgui( 1 ) } )
//hb_ThreadStart( { || TestHWgui( 1 ) } )
//hb_ThreadStart( { || TestHMGS() } )
//hb_ThreadStart( { || testhmg3() } )
//TestOOHG()
//hb_ThreadStart( { || Testwvt() } )
Testwvw()
hb_ThreadWaitForAll()
RETURN
Este teste precisou de 8 arquivos HBP, sendo que 7 geram LIB.
Com certeza não dá pra misturar tudo.
Misturar HWGUI com HMG, somente com pequenas mudanças na HWGUI (renomear duas ou três funcões).
Misturar HMG, HMG Extended e OOHG, sem chance, quase tudo é repetido.
Misturar GTWVG e GTWVT requer cuidado, porque pode estar usando tela de uma e teclado da outra.
OOHG somente chamando na thread principal.
GTWVW somente se for a Main(), porque faz tudo na janela Main()
E facilita muito dividir cada GUI em um sub-projeto, pra compilação de fontes de uma GUI não atrapalhar a compilação da outra. (arquivos usados em #include)
Ah sim, e isso requer uma errorsys mais padrão, porque a errorsys de uma GUI não funciona em outra GUI.
Adicionais:
OOHG é a única HMG que não funcionou em segunda thread
GTWVW sem chance de thread
Tudo bem, no uso normal ninguém vai misturar tanto.
Mas pode ser útil pra quem está interessado em migrar de uma LIB pra outra.
Ou quem tem vários aplicativos/sub-aplicativos em GUIs diferentes, e está pensando em padronizar ou juntar tudo.
Pensando grande:
Poderia ser o começo de uma padronização de LIBs a nível de fontes, pelo menos do que faz parte da API Windows, podendo fazer parte da hbwin.
As HMGs mesmo, parece que a maioria dos fontes C são iguais e poderiam ser centralizados em um núcleo comum.