A velha história: multithread é igual EXE separado, as janelas são independentes...
Tem aquilo de dialog modal e não modal, que só complica, porque é multithread.
Então fui pelo mais simples, eu acho...
Código: Selecionar todos
pThread := RunModule( { || cKeyboard := FWBrowseADO( @cnSQL, @oTBrowse, cFilterKey, bKeyboard, bUserFunction, ;
nFixToCol, aAdoFilterList, aBtnList ) }, "browse", "FIVEWIN" )
DO WHILE hb_ThreadWait( pThread, 0.1, .T. ) != 1
Inkey(0.3)
ENDDO
IF ! Empty( cKeyboard )
KEYBOARD cKeyboard + Chr(13)
ENDIF
RETURN Nil
Durante o teste se a thread terminou, o Inkey() a fim de não travar a janela atual GTWVG.
A execução vai retornar o que precisa pra KEYBOARD
O DO WHILE é necessário, senão o programa vai em frente sem esperar o retorno.
Nada diferente do que a maioria já conhece.
Em GUI costumam usar DoEvents() ou algo parecido, no harbour/GTWVG basta o próprio Inkey() pra isso.
Em GUI costumam usar dialog MODAL, pra travar a dialog anterior.
Neste caso uso o DO WHILE, e é muito mais do que dialog, é multithread.
E são dialogs de LIBs diferentes, GTWVG e FIVEWIN, não adianta querer que o MODAL de uma lib tenha efeito encima de outra LIB.
Nunca usei dessa forma, mas é a primeira situação com essa necessidade.
O KEYBOARD no fivewin não funciona, mas na GTWVG funciona.
Cada LIB faz sua parte e pronto.
Precisei alternativa pra isso, e resolvi assim.
É misturar LIBs, mas sem misturar fontes, fazendo cada LIB cuidar de sua parte.
E no caso de multithread, cuidar pra transferência de informação acontecer como deve.
Tem coisas que é mais fácil resolver com multithread, do que de outra forma.
Já pensaram se fosse integrar GTWVG e FIVEWIN, mexer nas classes internas de cada LIB pra funcionarem juntas ?
Pois é... com multithread foi relativamente fácil, não precisou alterar fonte de LIB nenhuma.
Lembrando:
Multithread pode ser usada em: GTWVG, GTWVT, HWGUI, FIVEWIN, e também em Linux.