Hola a [EMAIL PROTECTED]:

Reenvio el mensaje sin la imagen de la pantalla que habia incluido ya que me lo 
rechaza el Foro.
En esa imagen se ven 3 pantallas solapadas sobre la imagen del programa 
original.

Un saludo.
Juanra


----- Original Message ----- 
From: Juan Ramón Garcia 
To: forum.help400 
Sent: Thursday, July 10, 2008 5:27 PM
Subject: Re: Ventanas solapadas


Hola Susana:

¿Salud eterna? jua, jua, jua, es que me mondo, en serio, me he reido un montón 
al leerlo. Claro como soy novato en esto de ser autónomo no había caído en que 
si me pongo enfermo no trabajo (y no cobro), ¡ostras! de repente se me han 
curado todos los males, a ver si se me curan también las 3 hernias lumbares que 
he heredado de mi periodo de mobbing :-)

A ver, ahora en serio, yo vengo de S/36 aunque llevo con AS/400 ¿12, 14 años? 
he perdido la cuenta. Mi primer problema fué hacer que mis pantallas 
funcionaran como lo hacía el S/36 y no hicieran cosas raras (como este caso), 
después de muchas pruebas decidí compilar todas mis pantallas con ENHDSP(*YES) 
RSTDSP(*YES) DFRWRT(*NO), el primer parámetro para poder usar las cosas 
modernas (como las ventanitas), el segundo para que al volver de un programa 
que presenta otra pantalla (solapada o no) restaure la pantalla del programa 
llamador y la tercera para que no espere a llenar el buffer y que cuando yo 
haga un WRITE lo represente en pantalla en ese momento. Esto último es muy útil 
si tienes, por ejemplo, un subfichero donde vas mostrando el progreso del 
proceso, si lo haces con DFRWRT(*YES) no lo enseña cuando haces el WRITE, lo 
enseña cuando llena el buffer de salida (vaya Vd. a saber cuando). En principio 
estos parámetros vienen preconfigurados al revés para optimizar el rendimiento.

Lo de utilizar RETRN en lugar de LR=*ON lo hago algunas veces pero sólo en 
programas que son llamados con mucha frecuencia por el programa principal, de 
esta forma evito tener que abrir/cerrar archívos ya que el pgm secundario ya 
está cargado en memoria, lo que hago siempre en estos casos es, al finalizar el 
programa principal, llamar al programa secundario con un parámetro que le 
indica que encienda LR. Si no lo haces asi, el programa y sus archívos quedan 
abiertos y puedes tener problemas, a no ser que ejecutes RCLSTG coo bien decias 
al principio.

Por supuesto todas las pantallas que se solapan deben llevar un registro (DUMMY 
como dice Xavier o ASSUME como yo lo llamo) donde se especifica la palabra 
clave ASSUME, si no no solapará la pantalla anterior.

Te adjunto un ejemplo de un programa que llama a otro que abre una ventana 
solapada, que llama a otro y solapa otra ventana y llama a un 4º programa que, 
a su vez, solapa la última ventana:





Un saludo.
Juanra

PD: Si tenemos salud eterna ¿tampoco tenemos vacaciones nunca? :-(





  ----- Original Message ----- 
  From: FORO 
  To: 'forum.help400' 
  Sent: Thursday, July 10, 2008 1:35 PM
  Subject: RE: Ventanas solapadas


  Hola Juanra.  (por cierto, creo que has sido bendecido con la salud eterna 
¿no? o lo que es lo mismo  ¿ahora eres autónomo no? , pues nada bienvenido)

   

  Bien, vamos por partes,  creo que no me explique bien:

   

  1.- Están compiladas con RSTDSP(*YES) aunque con *NO actuan de igual manera. 

   

  2.- El problema es que cuando saca la 2ª ventana (3er programa) borra las dos 
anteriores (en mi primer correo mande las imágenes) y solo consigo evitarlo NO 
HACIENDO SETON LR en el programa 2º , Pero si hago esto, a partir de la segunda 
vez que se visualiza la ventana del PGM 2 los datos que se ven por detrás (los 
de la 1ª pantalla) SON LOS DEL PRIMER CICLO DE EJECUCION, si, si, aunque 
parezca mentira. Como ves, son 4 sentencias, os las envio y os invito a que lo 
comprobéis. Es realmente curioso. (Esta claro que mientras ejecuto pgm2 y pgm3 
el pgm1 esta parado y no puede refrescar los datos, pero la segunda vez que 
paso por PGM1,2 y 3 la hora y/o los datos que se ven por detrás de la ventana 
NO CORRESPONDEN A ESTE CICLO  SINO AL PRIMER CICLO Y puedo seguir pasando por 
las 3 que los datos pertenecen siempre ala primera vez que mostró P1. ¿no se si 
mas claro o mas oscuro?

   

  3.- Con el WRITE tampoco funciona:

   

  EXFMT P1

  CALL PGM2

  WRITE P1

  CALL PGM3 -à Cuando este programa muestra su ventana se han perdido las 2 
anteriores (CON Y SIN WRITE) (CON Y SIN RSTDSP *YES) (CON Y SIN ASSUME)

   

  Jose: ASSUME no me lo admite en un registro de Ventana, me da error de 
compilación, poniendolo en otro registro y utilizando el Keep tampoco consigo 
nada

   

  Pedro: Lo tuyo lo tengo que estudiar mas despacio. 

   

  Gracias a todos por vuestra atención 

   

  Aunque son 3 sentencias os adjunto los ficheros con los PGM para el que 
quiera verlo en detalle.

   

  Saludos.

   

  Susana 

   


------------------------------------------------------------------------------

  De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Juan Ramón Garcia
  Enviado el: jueves, 10 de julio de 2008 11:52
  Para: forum.help400
  Asunto: Re: Ventanas solapadas

   

  Hola Susana:

   

  No he contestado antes porque ya te habian facilitado la respuesta correcta, 
efectivamente hay que compilar con RSTDSP(*YES) pero eso lo que realmente hace 
es lo que te ocurre, guarda una imagen en memoria de la pantalla que tenía 
antes y la mantiene mientras vas solapando ventanas.

  Ten en cuenta que el primer programa queda en espera cuando llamas al segundo 
por lo que la hora no puede actualizarse.

  Tengo muchos programas hechos de esta forma, la solucion que encontre fue al 
volver al primer programa, desde otros que visualizan ventanas, forzar un WRITE 
de la pantalla para "refrescar" la informacion antes de volver a llamar a otro 
programa que solape una ventana.

  Es chapucero pero funciona.

   

  Un saludo.

   

  Juanra

  ChapuciSaurio

   

    ----- Original Message ----- 

    From: FORO 

    To: 'forum.help400' 

    Sent: Thursday, July 10, 2008 11:31 AM

    Subject: RE: Ventanas solapadas

     

    Gracias a todos por contestar.

    Marti, Jose, Rafa: Ya están compiladas con RSTDSP *YES , Aunque si las 
compilas con *NO, tampoco se aprecia ninguna diferencia.

     

    Manuel: Con tu propuesta es curioso lo que ocurre,  el primer ciclo de 
ejecución FUNCIONA PERFECTAMENTE, pero si os fijaís en la codificación de los 3 
programas, son sencillamente un bucle DO, pues bien, en el segundo ciclo, NO SE 
VISUALIZAN LAS PANTALLAS DEL PGMB Y PGMC, he estado mirando con el debug y el 
problema es que NO FINALIZA EL PROGRAMA, es decir: hace el RETURN pero no la 
sentencia SETON LR por lo que el programa no finaliza, y la siguiente vez que 
es invocado, encuentra el KC encendido y no entra en el bucle DO   he tenido 
que hacer un RCLRSC para que funcionar de nuevo. De hecho la curiosidad no 
termina hay, si modifico el PGMB para que no este condicionado de esa manera 

     

    *************** Principio de datos *****************

          FPGM02FM CF  E                    WORKSTN      

          C                     EXFMTFMT01               

          C   KC              MOVEL*ON       *INLR     

          C                     RETRN                    

     ****************** Fin de datos ********************

     

     

    SI QUE SE VE. pero ¡ESTO NO OS LO VAIS A CREER! 

     

    La imagen que se ve detrás del PGMB es el recuerdo de la primera vez que 
mostró la pantalla LO SE POR LA HORA QUE SACO EN LA ESQUINA SUPERIOR DERECHA DE 
CADA PANTLLA, es como si se lo guardara en memoria NO SE, ES MUY RARO. Si esto 
lo llevo a explotación,  lo que se ve siempre en la pantalla del PGMA son los 
datos del primer registro que visualicé, Si es un mantenimiento de clientes, al 
sacar la pantalla del PGMB SIEMPRE SE VEN EN EL PGMA los datos del primer 
cliente al que llame??????¿¿¿¿¿¿¿¿¿¿¿¿¿

     

    En fin, algún gallego en el foro con Meigas conocidas.

     

    ¿Cómo es posible que una chorrada tan gorda me este dando tantos dolores de 
cabeza?

     

    Un  Saludo

    Susana

    JaquecoSauria 

     

    P.D. Jorge: me olvidaba de ti, con el OVERLAY tampoco consigo nada, por lo 
menos aparentemente. Tambien gracias a ti



------------------------------------------------------------------------------


  __________________________________________________
  Forum.HELP400 es un servicio más de NEWS/400.
  © Publicaciones Help400, S.L. - Todos los derechos reservados
  http://www.help400.es
  _____________________________________________________

  Para darte de baja visita la siguente URL:
  http://listas.combios.es/mailman/listinfo/forum.help400
__________________________________________________
Forum.HELP400 es un servicio más de NEWS/400.
© Publicaciones Help400, S.L. - Todos los derechos reservados
http://www.help400.es
_____________________________________________________

Para darte de baja visita la siguente URL:
http://listas.combios.es/mailman/listinfo/forum.help400

Responder a