Detener scripts de formulario llamado desde de un bucle
sucede que tengo un bucle for como esto:
opensheet(w_cup,w_frame_form,1,original!)
for i=1 to dw_1.rowcount()
//aquí llamo a evento de form pasando variables globales
w_cup.trigger event ue_nuevo()
iVALOR = i<br class="scayt-misspell" data-scayt_word="w_cup" data-scaytid="117" />w_cup.trigger event ue_recupero()
//el form hace validaciones cálculos etc..
*
//al final llamo
w_declara_cup.TRIGGER event ue_guardar()
**
next
PREGUNTAS...
* 1.hay alguna forma de saber cuando termino su trabajo
** 2. SI ALGO SALIO MAL Y LAS VALIDACIONES DE ue_guardar() BOTAN UN return EJEM.
IF ib_parar then
MessageBox(sMESS,'ingrese dato de año anterior...',StopSign!, Ok!, 1)
return
// sleep(20) con esto la ventana se para congelado
end if
EL return DEBERÍA DETENER EL FORM. PARA COMPLETAR EL DATO Y PROCEDERÍA A GUARDAR EL FORM. Y CONTINUAR CON EL BUCLE FOR, COSA QUE NO SUCEDE ES COMO SINO HUBIESE return Y CONTINUA CON EL BUCLE FOR.
1 Respuesta
Como política personal, el control de los flujos o procesos lo determina uno, el nivel y el grado de depuración que deseas tener (control de errores), es algo que uno debe considerar e implementar siempre.
--Ordenando un poco...
opensheet(w_cup,w_frame_form,1,original!)
for i=1 to dw_1.rowcount()
//aquí llamo a evento de form pasando variables globales
w_cup.trigger event ue_nuevo()
iVALOR = i
w_cup.trigger event ue_recupero()
//el form hace validaciones cálculos etc..
*
//al final llamo
w_declara_cup.TRIGGER event ue_guardar()
**
next
-------------------
Para ser sincero no comprendo aun la naturaleza de tu flujo, noto que abre un windows, y haces uso de unos eventos del mismo (podría servir mas detalle al respecto, solo para entendimiento).
Por otro lado en la parte que especificas tus preguntas, me parece que te preguntas y también te contestas, pasa que como bien dices, los eventos, funciones ya sean de windows y/o generales (en el caso de las funciones), tienen la opción de retornar un valor, puede ser de distintos tipos y hasta objetos.
Podría valerte de dicha opción y si se presenta algún error o identifiques con validaciones los mismos, puedes retornar un valor booleano (True/false), y sobre ello implementar un EXIT para detener el proceso.
//si retorna falso, algo anduvo mal
if w_declara_cup.TRIGGER event ue_nuevo() = false then exit
if w_declara_cup.TRIGGER event ue_guardar()= false then exit
//También podrías declarar variables de tipo boolean y carga el retorno a dcha variabe y por ultimo dicha variable.
Boolean lb_retorno
lb_retorno = w_declara_cup.TRIGGER event ue_nuevo()
if not lb_retorno then exit
Si equivoque mi entendimiento con respecto a tu consulta, házmelo saber.
Gracias por su rpta,
el exit esta en funciones loop y es para terminar el proceso como dices y no quiero eso sino detenerme un rato en el form. abierto e ingresar dato para continuar con el proceso interativo.
Me parece buena idea lo de
lb_retorno = w_declara_cup.TRIGGER event ue_nuevo()
pero como haría para detener el proceso completar el form. y continuar con el proceso
probé con sleep(15) y efectivamente se detiene 15 seg. pero congelado todo el form.
En otra instancia me funciono con formularios response la diferencia es que ahí no tenia un
w_declara_cup.TRIGGER event ue_nuevo()
o algo similar
Básicamente lo que quiero es que me trabaje con una gran cantidad registros y sus dependencias, y las condiciones o validaciones están implementadas en los form., por eso el bucle
Gracias y SAludos
Si deseas trabajar a nivel de código fuente(osea Power builder), creo que la mejor opción para que como entiendo, de presentarse cualquier contingencia, el usuario tenga opción a interactuar con el aplicativo para atender dicha contingencia (aun así el proceso este iniciado, a la mitad o ya casi por acabar), tendrías que implementar una suerte de tratamiento de errores, aunque para ello tendrías que catalogar y validar todas los escenarios posibles, y como también mencionas, podrías trabajarlo con una ventana de tipo response, describiendo la contingencia y hasta sugerir la solución inmediata, en el peor de los casos podría también contemplar una opción que diga OMITIR/SALTAR, para saltar dicho registro(en el caso no se tenga una solución rápida o se desconozca la misma, solo de ser posible ya que aun no conozco la naturaleza de tu proceso ni el impacto de este proceso en cuestión sobre otros), he de suponer que cuentas con un campo indicador o un campo estado, con el cual jugarías para poder validar cuales no se llevaron a cabo o se saltaron.
Volviendo a lo de la ventana response, tendrías que prepáralo para que sea lo mas flexible posible para que pueda contemplar y manejar todos los escenarios posibles catalogados y/o por catalogar (uno nunca sabe que pueda inventarse el usuario) y obviamente sus validaciones del caso).
Otra opción, podrías validar la integridad de la data antes de procesar, así como una revisión y ahí vas cerrando aquellos registros que aparentemente no pasarían.. y luego de que el usuario los arregle, recién lanzas tu proceso.
Como comentario final, este proceso, evaluaste la posibilidad de llevarlo a cabo por bd, y de repente también validar lo que no se halla levado a cabo mediante un campo indicador o estado, ademas de eso un campo observación donde indique porque no se proceso y cual seria una solución o requerimiento a cumplir por parte del usuario, de repente de esa manera el usuario no podrá intervenir durante el proceso, pero al menos el proceso tampoco se truncaría, ya que procesaría aquellos que no tengan ningún problema y ademas te daría en cierto modo la solución para procesar a aquellos que no pudo en su ejecución, y esto ya se lo mostrarías al usuario para que lo resuelva y ejecute nuevamente el proceso. y así vas cerrando..
Son distintos modos, distintas ópticas, pero cualquiera de ellas puede servir, depende a cual te acomodes o te sirva mejor en tu caso especifico.
Valla chambita, después de hacer esto va a salir mas sabido, créeme, te lo digo por experiencia.
