Convertendo pra nultithread e gtwvg/qualquer lib

[JoséQuintas]

É relativamente moleza, ao mesmo tempo que precisa muita atenção.

Antes de começar, é se preparar.
Multithread é igual ter vários EXEs, do mesmo jeito, variáveis, arquivos abertos, etc. não ficam visíveis.
Precisa confirmar se errorsys, gt, etc. vão estar disponíveis em todas as thread, geralmente não.
No caso de erros, pode acontecer de ter programa sem tela ou tela sem programa (outras LIBs)

O jeito que acostumei a usar é o seguinte: MAIN fantasma, programa principal fantasma, só pra aguardar o resto fechar.
E acostumei a usar GTWVG, cada um que teste com a LIB que usar, mas acho que em Windows só sobra a GTWVT.

Renomeie sua MAIN pra MAIN2, e cria uma nova.

Código: Selecionar todos

PROCEDURE Main

   hb_ThreadStart( { || Main2() } )
   hb_ThreadWaitForAll()

   RETURN

PROCEDURE HB_GTSYS
   REQUEST HB_GT_WVG_DEFAULT
   RETURN

A princípio, com essa mudança tudo que tem passa a usar outra thread.

A próxima etapa é planejar sobre as "DIALOGs".
DIALOG é a janela criada para um processo.
Pode ter uma pra menu, uma pra login, uma pra cada módulo.

É obrigatório ter a MAIN, se fechar a main tudo se fecha.
Por isso uma Main oculta, assim o usuário não fecha.
Ela encerra quando mais nada estiver rodando (hb_ThreadWaitForAll())

[JoséQuintas]

Os módulos vão carregar uma nova janela hb_gtReload("WVG")
Se for lib gráfica, vai ser a dialog da lib.
É bom criar uma rotina intermediária, pra não ter que colocar isso em todo módulo.
Principalmente pra setar os defaults.
Alguns podem ser na Main oculta, outros não.

Código: Selecionar todos

PROCEDURE Main2

   LOCAL nOpc := 5

   SetMode(33,100)
   CLS
   DO WHILE .T.
      @ 1, 0 PROMPT "Cadastro 1"
      @ 2, 0 PROMPT "Cadastro 2"
      @ 3, 0 PROMPT "Cadastro 3"
   @ 4, 0 PROMPT "Este menu de novo"
      MENU TO nOPC
      DO CASE
      CASE LastKey() == K_EC
         EXIT
      CASE nOpc == 1
         //hb_ThreadStart( { || Opcao1() } )
      CASE nOpc == 2
         //hb_ThreadStart( {{ || Opcao2() } )
      CASE nOpc == 3
         //hb_TheeadStart( { || Opcao3() } )
   CASE nOpc == 4
      hb_ThreadStart( { || Main2() } )
      ENDCASE
   ENDDO
   RETURN

Tem uma "dialog" com menu, que se escolher a opção 4, vai abrir outra "dialog" com menu, e assim sucessivamente.

Basicamente é isso, dialogs à vontade e independentes.
Se quiser transformar qualquer dialog pra hwgui ou fivewin, está livre pra fazer isso.
minigui é mais limitada pra essas coisas, mas pode ser possível.

[JoséQuintas]

Multithread não enxerga variáveis.
Pode transformar as variáveis públicas em STATIC ou THREAD STATIC.

Código: Selecionar todos

STATIC FUNCTION AppUserName( xValue )
   STATIC sAppUserName := ""
   IF xValue != Nil
       sAppUserName := xValue
   ENDIF
   RETURN sAppUserName

Sempre que precisar o nome do usuário, só usar AppUserName()
Ou pra definir qual é o usuário AppUserName( "nome" )
Isso vai deixar o usuário visível em todas as threads.
Com a vantagem do compilador testar se escreveu direito.
Vai dar falta de função, caso tente compilar com nome errado. APPusuario() por exemplo.

[JoséQuintas]

E pra juntar hwgui por exemplo ?

Costumo usar assim:

Código: Selecionar todos

hb_gtReload( "WVG" )
InicProc()
DialogHWGUI()

InitProc() faz parte de uma INIT PROCEDURE.
Pra quem não sabe, INIT FUNCTION/PROCEDURE, pode ter várias, são rotinas pra serem executadas quando o programa inicia.
Elas não seguem uma sequência exata, se tiver várias, apenas são executadas logo de início.

Você poderia ter uma init procedure assim:

Código: Selecionar todos

INIT PROCEDURE MySetup

   SET DATE BRITISH
   SET EXCLUSIVE OFF
   SetMode(33,100)
   CLS

   RETURN

No fonte:

Código: Selecionar todos

PROCEDURE Main

   @ 1, 10 SAY Date()
   Inkey(0)
  
   RETURN

Vai entrar a configuração antes de Main.
É apenas exemplo, não vão sair colocando isso, porque depois trocam pra LIB gráfica, e isso daria problema.
Isso roda só no início do aplicativo, não roda inicial em todas as threads.
Esse é o ponto aonde as LIBs podem não se comportar direito em multithread, porque as threads rodam sem o init.

Pelo mesmo motivo, chamo a rotina InitProc() de HWGUI, porque a thread precisa dela, que só rodou na Main.

Não tenho isso em todos os fontes.
Usei algo assim:
hb_ThreadStart( { || DoPrg( "teste" ) }
DoPrg faz a configuração antes de chamar qualquer módulo.

O módulo passa a ter um fonte comum, contém o que precisa, sem mexer com rotinas de configuração.

[JoséQuintas]

Com base nisso, o que dá pra fazer ?

Pode criar login em hwgui
Pode criar menu em hwgui
Pode criar browse em hwgui
Pode criar módulos em hwgui.
O mesmo com fivewin.

A partir daí, vai da imaginação.

HWGUI pode não ter os recursos de FIVEWIN ou MINIGUI, mas permite o uso desse jeito, e atende o necessário.
E é grátis.

FIVEWIN tem a opção grátis, mas é fixada em BCC, e não tem multithread.
Não me interessa fazer testes com essa versão grátis, porque não uso BCC, e seria diferente do fivewin atual.

[JoséQuintas]

Evitem ao máximo o uso de variáveis PUBLIC e PRIVATE em multithread.
Aquelo recurso que o harbour tem, de passar tudo pra thread.
O aplicativo pode entrar em colapso conforme a situação.
Acho até que muita LIB GUI dá problema por falta desse controle.

No harbour existe hb_Mutex() pra evitar problemas no uso de PUBLIC,PRIVATE, mas isso é feito POR VARIÁVEL, vai ser muito mais trabalhoso do que usar local.