PC Toledo

Apesar da "complicação", procuro deixar essa parte separada do resto.
Dessa forma os fontes ficam de um jeito normal.
Vai abrir duas janelas, mas uma fica encima da outra.
Mova pros lados.
Em cada janela, F9 abre o browse fivewin, e clicando ou teclando enter, digita o código nos gets.
Esse é um bug, ao ficar clicando em cada browse em seguida.
Modificando no fivewin pra THREAD STATIC aResources parece resolver.

STATIC = variável comum pra tudo
THREAD STATIC - cada thread tem sua própria variável

O erro é uma janela/thread destruindo resource da outra.
Ao alterar o tipo de variável, cada janela/thread tem seus próprios resources, e só destrói o que criou.
Mais eficiente do que controles alternativos.

Essa rotina parece até funcionar em fivewin anterior a 24.09 sem alteração.
Mas na prática, o problema de janela modal vai acontecer conforme aumenta o número de janelas/níveis.

O que tem na linha 45 da test_fwBrowse() um objeto? tente deixá-lo PUBLIC para ver se resolve, sim?

Regards, saludos.

Tá resolvido.

Acho difícil PUBLIC resolver alguma coisa.
Estamos falando de multithread, onde PUBLIC não é vísivel.
E onde Mutex() em determinadas variáveis seria necessário.
E onde API Windows não é a mesma coisa com multithread.
Melhor deixar do jeito que já deu certo.

Mesmo link, teste expandido.
Que tal browse do mesmo dbf, sem uma dialog bagunçar a outra ?
Com multithread isso é possível.

fivewin é avançado.... tem classe pra trabalhar com dbf em várias dialogs....
Pois é...
Trabalhar com DBF em multithread é do jeito simples de sempre.
Talvez pra SQLRDD (ou RDDSQL sei lá) precise ser assim também.
Talvez pra letodb, sei lá, não faço idéia, porque não uso.