Mensajes durante un proceso...

[noe aburto]

Saludotes:

Estimados, las funciones abajo definidas las uso para poner un mensaje en pantalla cuando estoy calculando o procesando algo que tarda algunos minutos:
Ej.

Code: Select all  Expand view

bPant:=mensaje('Calculando inventario','espere...')
while !eof()
 ...
 ...
 CursoMens('No. parte '+cPieza
end
eval(bPant)
 

el problema de este codigo, es que en algun momento durante el proceso si entro a otra aplicacion o tarea en mi pc, esté dialogo me pone en el titulo "(no responde)", pero si lo esta haciendo
Alguien de ustedes maneja algo algo parecedio a lo que hago, pero sin datalles del que platico. Compartan algun ejemplo...!!!

Code: Select all  Expand view

function Mensaje(cMensaje,cTitulo,cPie,cBitMap)
local oFont,nAncho,nMensaje,oSay,oBtn,oPie,nR

default cBitMap:='GOMENS'
aadd(aMensaje,NIL) ; nMensaje:=len(aMensaje)
if cTitulo==NIL
 cTitulo:="Procesando..."
endif
if ISOBJECT(aMensaje[nMensaje])
 aMensaje[nMensaje]:End()
 aMensaje[nMensaje]:=NIL
 SysRefresh()
endif
DEFINE FONT oFont NAME "ARIAL" SIZE 0,-12
nAncho:=max(len(cMensaje),len(cTitulo))
if cPie<>NIL
 nAncho:=max(nAncho,len(cPie))
endif
nAncho+=10
DEFINE DIALOG aMensaje[nMensaje] FROM 0,0 TO 6,nAncho;
       TITLE Ota(cTitulo) STYLE DS_MODALFRAME
SET FONT OF aMensaje[nMensaje] TO oFont
if cMensaje==NIL
 cMensaje:='Un momento...'
endif
aMensaje[nMensaje]:lHelpIcon:=.f.
aMensaje[nMensaje]:nWidth:=max(len(cMensaje),len(cTitulo))*8

CursorWait()

@ 0,0 BITMAP oBmpMens RESOURCE cBitMap SIZE 35,35 ADJUST PIXEL NOBORDER OF aMensaje[nMensaje]

oSay:=TSay():New(Row2Pxl(0.8),Col2Pxl(6),{||Ota(cMensaje)},aMensaje[nMensaje],,aMensaje[nMensaje]:oFont,.F.,.F.,.F.,.T.,COLOR_NEGRO,,SAYS_LARGO(cMensaje,aMensaje[nMensaje]:oFont),10,.F.,.F.,.F.,.F.,.F.)

if cPie<>NIL
 oPie:=TSay():New(Row2Pxl(1.5),Col2Pxl(6),{||Ota(cPie)},aMensaje[nMensaje],,aMensaje[nMensaje]:oFont,.F.,.F.,.F.,.T.,COLOR_AZUL,,nAncho*DLG_CHARPIX_W/2,10,.F.,.F.,.F.,.F.,.F.)
endif

ACTIVATE DIALOG aMensaje[nMensaje] CENTER NOWAIT

SysRefresh()

return {||CursorArrow(),CierraMens()}


// --- Cierra un Mensaje
static function CierraMens()
local nMensaje:=len(aMensaje)

if ISOBJECT(aMensaje[nMensaje])
 aMensaje[nMensaje]:End()
endif
oBmpMens:End()
SysRefresh()
adel(aMensaje,nMensaje) ; asize(aMensaje,--nMensaje)
return NIL


// --- Despliega en area de mensaje el curso del avance
function CursoMens(cMensaje)
local nMensaje:=len(aMensaje),i

if cMensaje<>NIL
 i:=aScan(aMensaje[nMensaje]:aControls,{|oCtrl|oCtrl:ClassName=='TSAY'})
 if i>0
  aMensaje[nMensaje]:aControls[i]:nWidth:=Max(len(cMensaje)*8,aMensaje[nMensaje]:aControls[i]:nWidth)
  aMensaje[nMensaje]:aControls[i]:VarPut(Ota(cMensaje))
  aMensaje[nMensaje]:aControls[i]:Refresh()
 endif
endif
return NIL

 

[hmpaquito]

Que los dioses del olimpo inspiren al que no sabe... pero eso se resolveria si tuvieramos multihilo.
Como no tenemos multihilo, entonces tenemos que ir sysrefrescando el sistema... que funciona de manera torpe porque puede que permita refrescar la pantalla pero a un alto costo de tiempo de ejecucion y ademas no permite que el usuario haga nada.

Ojito con la programacion multihilo: piensese en lo que pasaria si se abrieran dos hilos usando las mismas areas de trabajo: el caos. En general, pienso yo, que el multihilo en una aplicacion hay que trabajarlo, tanto que hay que cambiar un tanto la manera de pensar.

El super mega hacking que para esto se podria aplicar seria llamar al ejecutable de nuevo pero parametrizado. Ejemplo si el programa se llama miprograma.exe, entonces se llamaria con la opcion miprograma /LANZALISTADO. Si esto se hace con cada opcion del menu del programa tendremos un pseudo entorno multihilo.

Espero te sirva.

[sjingo]

Estimado NOE

Podrías usar un MsgMeter, con el cual hasta hoy no he tenido esos inconvenientes ....la verdad no me he fijado, y pensándolo bien puede que suceda lo mismo de todas formas es otra opción que la puedes probar:

Code: Select all  Expand view

MsgMeter({ | oMeter, oText, oDlg, lEnd | FuncionConTareaExtensa(oMeter, oText, oDlg, @lEnd))  },"Calculando","Espere")  

La función que hace algo quedaría más o menos así:

Code: Select all  Expand view

function FuncionConTareaExtensa(oMeter, oText, oDlg, lEnd)
local nreg:=0
cursorwait()

oText:SetText("Obteniendo Nro de Registros...")
oMeter:nTotal = RecordCount() //O la función que devuelva el total de registros

while !eof()
   ...
   ...
  nreg++
  oMeter:Set(nreg)
  oText:SetText('No. parte '+cPieza)
  sysrefresh()         //Puede que no sea prudente,
  cursorwait()        // de pronto se hace más lenta la tarea
end

lEnd:=.t.
 

Saludos

[sysctrl2]

Code: Select all  Expand view

function main()
 local oWait

waiton( space(40) , @oWait )

FOR I := 1 TO 100
   oWait:say( 1, 1, "procesando reg. " + str( i,10)  )
  sysrefresh()
NEXT

waitoff( @oWait )
return nil

function waitOn( cCaption, oWait, cTitle )  //simula un waiton de grump
   LOCAL nWidth
   local lVal := .t.
   local oBrush

   LOCAL   bAction  := { || .t. }
   default cTitle := "Usuario, un momento por favor"
   DEFINE BRUSH oBrush COLOR RGB( 192, 216, 255 )   //rosa


   IF cCaption == NIL
      DEFINE DIALOG oWait ;
         FROM 0,0 TO 12, Len( cTitle ) + 4 ;
         STYLE nOr( DS_MODALFRAME, WS_POPUP ) BRUSH oBrush TRANSPARENT
   ELSE
      DEFINE DIALOG oWait ;
         FROM 0,0 TO 12, Max( Len( cCaption ), Len( cTitle ) ) + 4 ;
         TITLE cTitle ;
         STYLE DS_MODALFRAME BRUSH oBrush TRANSPARENT
   ENDIF

   oWait:cMsg   := cCaption

   nWidth := oWait:nRight - oWait:nLeft

   //@ 01, 1 BUTTON " &Cancelar " OF oWait SIZE 60, 12 ;
   //ACTION ( lVal := .f., oWait:End() )

   ACTIVATE DIALOG oWait CENTER ;
      ON PAINT oWait:Say( 1, 0, xPadC( oWait:cMsg, nWidth ) ) ;
      NOWAIT
   sysRefresh()
return (lVal)

function WaitOff( oWait )
   IF valtype(oWait) <> 'U'  /* waiton has to be called first! */
      oWait:end()
      oWait := NIL
   ENDIF
   sysRefresh()
RETURN NIL

[thefull]

Buenas, te aclaro;

[Ojito con la programacion multihilo: piensese en lo que pasaria si se abrieran dos hilos usando las mismas areas de trabajo: el caos. En general, pienso yo, que el multihilo en una aplicacion hay que trabajarlo, tanto que hay que cambiar un tanto la manera de pensar.]

Cuando abres un thread, se abre un nuevo espacio para la tabla, las tablas NO SE comparten entre hilos. Puedes ENVIAR una tabla abierta en un hilo hacia otro, detach.
Imagina un servidor web hecho en harbour, que por cierto lo tienes en /contrib/httpd, cada peticion puede abrir la misma tabla en hilos diferentes , SIN NINGUN PROBLEMA, es como si tuvieras
distintos alias, pero se llaman igual.
Asi, un proceso que atiende peticiones, es MUY FACIL convertilo a multihilo, y APENAS TIENES QUE HACER NADA!!

Thread 1
open table test.dbf
goto 5
? "recno" // 5

Thread 2
open table test.dbf
goto 3
? "recno" // 3

[hmpaquito]

Cuando escribia sobre eso, me acordé de ti .. no se si te habia leido sobre multihilo en tu blog o en algun otro sitio.

Gracias por la explicación.

Para mi la pregunta seria ¿ Entonces podemos (harbour-fwh) trabajar en multihilo o sólo aquel codigo que no haga uso de la GUI ?
Es decir ¿ Hay forma (humana) de evitar el "no responde" que da una malísima impresión al usuario ?


pd. ¿ Para cuando una actualizacion de tu famoso "bucaneros" ? En estos foros se puede ver que nos hace mucha falta conocer las posibilidades de Harbour. Ejemplo 1) Recientemente en este foro ha resultado sorpresiva para numerosos foreros la existencia de hb_dbcreatetemp(). Ejemplo 2) En el changelog de harbour, druzus no para de poner cosas... que cuesta entender de qué va. El ultimo una mejora sobre GtTrm... ¿ Qué es ? ¿ Un GT ? ¿ Como podriamos hacer uso de él ? ¿Funciona en modo GUI ? En fin... a veces pareciera que usamos Harbour porque simplemente es compatible con Clipper

[thefull]

Buenas

Para mi la pregunta seria ¿ Entonces podemos (harbour-fwh) trabajar en multihilo o sólo aquel codigo que no haga uso de la GUI ?
Es decir ¿ Hay forma (humana) de evitar el "no responde" que da una malísima impresión al usuario ?

Aqui el Master Zen Antonio es el que tiene que decir. Desgraciadamente, estoy más enfocado a BackEnd de aplicaciones, a temas de APIs , interfaces y similar,
y tengo a Fivewin abandonado.
Pero creo que por aqui alguien usal multihilo y si no interviene con FWH , creo que no deberias tener mayor problema.
De todas maneras el "NO RESPONDE" me sale a diario en cualquier producto de Microsoft o hasta el mismo Chrome.
Tambien se puede hacer un hb_idle() que vaya haciendo un sysfresh de vez en cuando, es cuestión de probar.

pd. ¿ Para cuando una actualizacion de tu famoso "bucaneros" ?

Puff... A día de hoy, es imposible ;-( Ahora estoy empezando a usar mis conocimientos de Java, hace 5 años que di un curso, y ahora me pongo con Android.

En estos foros se puede ver que nos hace mucha falta conocer las posibilidades de Harbour. Ejemplo 1) Recientemente en este foro ha resultado sorpresiva para numerosos foreros la existencia de hb_dbcreatetemp(). Ejemplo 2) En el changelog de harbour, druzus no para de poner cosas... que cuesta entender de qué va. El ultimo una mejora sobre GtTrm... ¿ Qué es ? ¿ Un GT ? ¿ Como podriamos hacer uso de él ? ¿Funciona en modo GUI ? En fin... a veces pareciera que usamos Harbour porque simplemente es compatible con Clipper

Pues yo acabo de enterarme el uso de BMDBFNTX!!
El Changelog y lo que ha poniendo Przemeck , con ver los ejemplos, pues se sacan conclusiones
Y si, creo que la mayoría sigue con Harbour por ser simplemente compatible con Clipper.
En mi empresa implementan todas estas cosas por que yo previamente lo he valorado y
probado, pero los compañeros, ni idea de practicamente de nada, solo de Clipper.
Y el tema de POO, ya lo dejo por perdido para algunos

Cuando les di la herramienta de indexacion multihilo a los de soporte, no sabes como lo agracecieron