Função WaitRUN para Harbour

[JoséQuintas]

Estou tendo problemas com o RUN.
Já testei SwpRunCmd(), Run, HB_Run() e HB_ProcessRun()
Problema: Tudo bem, o programa aguarda a execução do que foi chamado, mas não se pode mexer na tela, senão o Windows acusa "este programa não está respondendo", porque fica travado.
Existe alguma solução pra isso no Harbour?

Obs.
Utilizei a saída para o DOS como teste, run (GetEnv("COMSPEC"))
E no HB_ProcessRun() não há espera e nem janela aberta

[Pablo César]

Oi Jo´se, você já viu o exemplo postado pelo Leonardo ?

https://pctoledo.org/forum/viewto ... ell#p75529

[Abel]

tive este problema e era um terminal, toda hora aparecia "nao esta respondendo" na barra de titulo.

abri uma janela msdos,

fiz um ping <nome do servidor> -t e vi que perdia varios pacotes...., ai pedi para o cliente chamar alguem para verificar a rede.

as vezes ainda aparece "nao esta respondendo", mas é so clicar na janela, que volta tudo ao normal.

Abel

[Pablo César]

Isso aí Abel, valeu pelo seu esclarecimento. Isso é algo que as vezes não prestamos atenção. Bem lembrado !

[JoséQuintas]

Também não deu certo.
A execução funciona, mas o programa fica travado esperando resposta.
No Windows existe um limite de tempo para um programa responder, e não pode ficar a espera de outro indefinidamente.
Aqui um protótipo de uma idéia, mas ainda vou pesquisar como fazer, pra ver se o resultado prático é o mesmo teórico.
Obs. Em console não existe esse limite, só em GUI

Código: Selecionar todos

Terminou := .f.
MultiThreat {|| outroRun("cmd.exe")}
do while .not. terminou
   Inkey(3)
enddo

function outrorun(comando)
run (comando)
terminou := .t.
return NIL

[asimoes]

Para ajudar:

lOk:=MyRun( "Teste.pdf" )

Código: Selecionar todos

FUNCTION MYRUN( cComando )
LOCAL oShell, lOk:=.T.
/*
O WScript.WSHShell

O WSHShell é um objeto que permite acesso direto ao shell do Windows. Ele possui métodos e propriedades básicas para a criação de qualquer script,
como executar programas, modificar o registro, gerar eventos no log de eventos do computador, entre outros.

Para se familiarizar com o conteúdo que veremos adiante, recomendo que leia as informações sobre os métodos e propriedades do objeto WSHShell no link abaixo:

http://msdn.microsoft.com/library/en-us/script56/html/wsoriWshShellObjectPropMeth.asp

Imagine a seguinte situação: você é um administrador que precisa criar um script de logon, de forma que um programa seja executado sempre após o logon do usuário.
Vamos analisar este problema.

Uma das formas de resolver tal problema é criar um script que carrega um programa e atribuir como script de logon dos usuários, seja nas propriedades dele
no AD ou por uma GPO.

Veja o script abaixo:

Set objShell = CreateObject("Wscript.Shell")
objShell.Run "\\server\share\programa.exe"

O script acima resolve o problema. No entanto, ele possui um problema: ele executa o aplicativo em primeiro plano, e todas as informações são exibidas na tela,
o que costuma confundir os usuários. Outro detalhe é que o script apenas é chama o programa e continua sendo executado. 
Em algumas situações, pode ser necessário executar o programa e somente depois dele ter terminado continuar o script.
Esses dois problemas podem ser resolvidos modificando um pouco o script. Veja:

Set objShell = CreateObject("Wscript.Shell")
objShell.Run "\\server\share\programa.exe",0,true

Foram adicionados dois parâmetros ao método Run, separados por vírgula. O primeiro parâmetro, um zero, abre o programa como uma janela escondida.
O segundo parâmetro, true, faz com que o script espere até o programa ser terminado. Esses e outros parâmetros estão no seguinte link:

http://msdn.microsoft.com/library/en-us/script56/html/wsoriWshShellObjectPropMeth.asp

A vantagem de usar um script assim é a manutenção fácil. Caso o programa precise ser alterado, ou mesmo mais um programa precise ser executado,
fica fácil alterar o sistema. Este script ainda pode ser melhorado. Uma primeira idéia seria fazer ele listar os programas em uma determinada pasta
no servidor e executar todos. Assim, bastaria incluir um programa novo lá que automaticamente todos os usuários executariam o programa durante o logon.
*/


   TRY
      oShell:=Win_OleCreateObject( "WScript.Shell" )
   CATCH
      TRY
         oShell:=Win_OleCreateObject( "WScript.Shell" )
      CATCH
         lOk:=.F.
      END
   END
   IF lOk
   
      //oTeste:=oShell:Exec("calc")
      //DO WHILE oTeste:Status = 0
      //   HB_IDLESLEEP( 1 ) 
      //ENDDO
      //btn = oShell:Popup("Testar Sim ou Não?", 7, "Questão:", 4 + 32)
      //Alert(Str(btn))
      //Alert(oShell:CurrentDirectory)
      
      TRY
        oShell:Run( "%comspec% /c " + cComando, 0, .T. ) //.F. = NÆo espera a aplica‡Æo fechar, .T. espera.
      CATCH
         lOk:=.F.
      END
      oShell:=Nil
   ENDIF
RETURN lOk

[JoséQuintas]

Com isso o programa não dá o travamento windows, mas não abriu o prompt, e precisou ser fechado pelo gerenciador de tarefas.
E ao que parece, o cmd.exe chamado ficou zumbi no gerenciador de tarefas também.
Vou pesquisar mais depois, incluindo as opções do script que tem aí, e aquele protótipo que coloquei usando multithreat.

[JoséQuintas]

Não consegui encontrar referência do multithread.
No google, a palavra Harbour acaba desviando pra tudo que se refere à universidade americana.
Queria testar colocar o run em multithread porque talvez resolva meu problema.
Só rodar o run em multithread e checar quando termina.
Até achei um blog que mostra detalhes das funções, mas sem exemplo prático.

[asimoes]

José,

No seu script de compilação acrescente a instrução:
-mt

Na pasta C:\Projetos_SVN\harbour\contrib\gtwvg\tests você vai encontrar um exemplo com multithreat, veja a procedure do fonte demowvg.prg

Código: Selecionar todos

PROCEDURE WvtConsoleGets( nMode )

   DEFAULT nMode TO 0

   IF hb_mtvm()
      Hb_ThreadStart( {|oCrt|  hb_gtReload( 'WVT' ) , ;
                               oCrt := hb_gtSelect(), ;
                               iif( nMode == 0, WvtNextGetsConsole(), GoogleMap() ) , ;
                               oCrt := NIL        } )
   ENDIF

   RETURN

[JoséQuintas]

Aqui deu certo, mas a comunicação com a thread foi via arquivo.
Tentei até com variável pública, mas não foi.

Código: Selecionar todos

Procedure Main
@ 1, 0 Say "começou"
cComando := "cmd.exe"
RunWait(cComando)
@ 2, 0 Say "Parou"
Inkey(100)
Return

Function RunWait(cComando)
HB_MemoWrit("teste.txt","teste")
Hb_ThreadStart( {||OutroRun(cComando)} )
nCont := 1
Do While File("teste.txt")
   ? nCont
   nCont += 1
   Inkey(1)
Enddo
Return NIL

Function OutroRun(cComando)
Run(cComando)
fErase("teste.txt")
Return NIL   

[Abel]

Jose, segue minha rotina, mande exemplos do que vc esta querendo executar para gente ver se consegue te ajudar.
abracos,

Código: Selecionar todos

FUNCTION MYRUN(cComando, rL_ESPERA)
local oShell, RET
IF rL_ESPERA=NIL
   rL_ESPERA=.T.   // rL_ESPERA = .F. SO DEVOLVE O CONTROLE P/SISTEMA QDO TERMINAR EXECUCAO
ENDIF                   // rL_ESPERA = .T. DEVOLVE O CONTROLE AO SISTEMA MESMO SE O PROGRAMA CHAMADO AINDA ESTIVER SENDO EXECUTADO

oShell := CreateObject("WScript.Shell")

RET:=oShell:Run("%comspec% /c "+cComando,0, rL_ESPERA)
oShell:=NIL
RETURN IIF(RET=0,.t.,.f.)

com ela alterei praticamente todos os pontos que o sistema tinha uma chamada externa.

faz um teste simples
myrun("notepad.exe",.t.) // ele trava o programa q chamou ate fechar o notepad
myrun("notepad,exe",.f.) // ele abre o notepad e fica os dois programas funcionando separadamente.

um site eu abro assim:
myrun("cmd /c start /max http://www......com.br",.f.)

myrun("executa.exe",.f.) // executa e libera o processamento mesmo se o mesmo estiver aberto.

[JoséQuintas]

Já passaram no grupo no Harbour.

Hb_ThreadStart( @OutroRun(), cComando )
or
Hb_ThreadStart( {| cVar |OutroRun(cVar)}, cComando )

Em janela Windows não GUI, tipo GTWVT ou GTWVW, a janela não pode esperar indefinidamente pela resposta do outro programa.
O Windows considera isso como programa travado.
A alternativa é a rotina do run estar em uma thread separada, e essa thread pode ficar aguardando resposta, sem travar a que está chamando.

Uma das situações, por exemplo, é:
chamo um programa pra gerar o PDF, e preciso aguardar que o PDF seja gerado antes de prosseguir.
Em console tudo ok, mas se usar GUI, só a alternativa acima.

[Abel]

pessoal, estou usando o comando hb_run("arj t -va -r backup.arj") para que o sistema compilado com -gui,
abra uma nova janela msdos e execute o arj dentro dela., este comando é para testar o arquivo backup.arj

o que ocorre é que abre a segunda janela mas roda tao rapido e ao terminar a janela ela fecha e nem consegui ver o que foi processado.

será que é possivel executar o comando e pausar a janela msdos que foi aberta peo hb_run antes da mesma fechar ?

Abracos,
ABEL

[Pablo César]

Uma ideia seria direcionar o comando para arquivo e depois ler-lo.

[JoséQuintas]

Só pra acrescentar mais opções...
Tava olhando o help do start do Windows:
"Titulo" - Titulo pra janela
/d Path - Path de trabalho
/min /max - minimizado ou maximizado
/wait - aguardar o término

Então, comportamento diferente para:
Start /wait programa.exe
Start programa.exe

Achei interessante a opção do título, e em alguns casos, rodar minimizado.
Start "Sub-rotina XXXXX" /min programa.exe

Aqui usando Windows 7. Não sei isso está disponível em outras versões.