No de detiene a esperar una clase de tipo modal

[Germán Montini]

Hola, hace poco les consulté porque no se detenia la ejecucion del programa a esperar en un formulario de ingreso, ahora me esta sucediendo lo mismo con un formulario que creé, para poder hacer busquedas dentro de una tabla, le puse todas las propiedades que consideraba que debia cambiarse, pero no se detiene a esperar.

En la ocasión anterior el problema que tenia era que no se por que motivo, al cambiarle la propiedad _SCREEN.VISIBLE = .f., no se detenia, cuando saqué esa sentencia del programa, comenzó a funcionar normal.

Las propiedades que cambié en el form de esta clase son las siguientes:

    AllwaysOnBottom        .t.

    BorderStyle                   1 - Fixed Single

    Closable                        .f.

    ContinousScroll             .f.

    ControlBox                    .f.

    Desktop                         .t.

    MaxButton                     .f.

    MinButton                      .f.

    ShowInTaskBar             .f.

    ShowTips                       .f.

    ShowWindow                2 - As Top-level form

    Visible                            .f.

    WindowType                  2 - Modal

 

y el procedimiento que lo llama es el siguiente

 

FUNCTION

Selecciona

PARAMETERS

m._Tabla, m._CampoBusq, m._Filt1, m._Filt2, m._Filt3, m._Filt4

SET CLASSLIB TO C:\AZUCAR\CLASES\CAMPOS.VCX

oBusq =

CREATEOBJECT("FormBsq", m._Tabla, m._CampoBusq, m._Filt1, m._Filt2, m._Filt3, m._Filt4)

oBusq.

visible = .t.

READ EVENTS

m.Retorna = oBusq.Retorna

oBusq =

NULL

RELEASE

oBusq

RETURN

m.Retorna

Muchas Gracias

Germán Montini

Analista de Sistemas

S.M. de Tucumán

 

 

[Guillermo MDQ]

Fijate que un formulario de nivel superior siempre es No Modal, independientemente de lo que tenga la variable WindowType.
Proba cambiando el valor de la  propiedad  ShowWindow a 1 - In Top-Level Form a ver si te funciona.

Saludos
Guillermo

[Fernando D. Bozzo]

Hola Germán, eso ya te lo había respondido en el otro hilo: los forms de nivel superior no pueden ser modal, es como intentar que al abrir la calculadora de Windows se bloquee el Internet Explorer, son ventanas separadas, aunque sean lanzadas por Windows.

[Germán Montini]

Hola Fernando, si, tenes razón, lo que sucede es que no se como armar una pantalla de busqueda, para ser mas explicito, lo que deseo es que por ejemplo te pide la provincia, uno inserta el código, si este no existe, entonces llama a un form en el cual este tiene un boton de opción, por si puede ser de diversas busquedas, por ejemplo en cliente, que se puede buscar por Nombre de cliente, nro de CUIT, o numero de Documento, despues un textbox para escribir el filtro, y por tercero un grid en el que mostrará los registros coincidentes.

 

 

La cuestión es que a esto lo hice en el valid de cdIva por ejemplo, entonces si no encuentra llamo a un from que es una clase, pero ahí necesitaria que se detenga hasta que se seleccione el correcto.

Capaz que estoy equivocado y en realidad lo que debia es llamar a un form, enviandole los parametros y que me deuelva el resultado.

En ese caso, detendría la ejecución del form principal?

y como es el codigo para lanzarlo? es DO FORM Bsuqueda WITH Param1, Param2, Param3, Param4 TO ParamResultado

 

Muchas Gracias

 

Germán Montini

Analista de Sistemas

S.M. de Tucumán

 

 

[Víctor Hugo Espínola Domínguez]

Hola Germán

>oBusq.visible = .t.

>READ EVENTS

en lugar de estos comandos usa:

oBusq.Show(1)

Saludos,

Víctor.

[Germán Montini]

Muchas Gracias Victos, parece que ahi funciona bien.

Saludos

 

Germán Montini

Analista de sistemas

S.M. de Tucuman

[Germán Montini]

Victor, te queria consultar con respecto al codigo este que me respondiste.

Como esta es una clase, pero me tiene de devolver un valor, como hago para recuperarlo a ese codigo.

 

o seria

  Variable = oBusq.Show(1)

 

Te consulto porque cuando salgo de la funcion, supuestamente no se habia borrado de memoria oBusq, y al tratar de recuperar la propiedad oBusq.Retorno, me doy con que oBusq = NULL.

 

 

Saludos

 

Germán Montini

Analista de Sistemas

S.M. de Tucumán

 

From: Víctor Hugo Espínola Domínguez

Sent: Tuesday, June 11, 2013 7:11 PM

To: publicesvfoxpro

Subject: Re: [vfp] No de detiene a esperar una clase de tipo modal

[Fer]

Cuando una clase form se muestra con Show() nunca se debe liberar desde dentro del mismo con Release, sino con Hide (), justamente para luego poder seguir usando el objeto desde donde se llamó. Y en QueryUnload debe ir NODEFAULT y Hide por lo mismo.
El objeto lo debe liberar quien lo llama con objeto. Release ()

[Germán Montini]

Muchas gracias Fer, se solucionó asi.

En el aceptar puse oBusq.Hide()

en el procedimiento que lo llama, al salir puse oBusq.Release()

Hasta ahi todo bien, pero ahora, al eliminar el formulario, me debiese volver al formulario que lo llama, y no es asi, queda oculto el formulario.

 

Saludos

 

Germán Montini

Analista de Sistemas

S.M. de Tucumán

 

[Fernando D. Bozzo]

Pero cuando hacés la llamada a oBusq.Show() hacés algo con el formulario padre para que se oculte?

[Germán Montini]

Hola Fernando, no lo oculto, si se lo ve atras de este formulario, pero me pasa a la pantalla de visual foxpro.

Saludos

---

Date: Thu, 13 Jun 2013 13:59:20 -0700
From: fdb...@gmail.com

To: publice...@googlegroups.com
Subject: Re: [vfp] No de detiene a esperar una clase de tipo modal

[Fer]

¿los forms son de nivel superior o se muestran en la ventana principal?

[Fernando D. Bozzo]

Según tu definición inicial, tus forms son de nivel superior, entonces, ¿por qué tenés la ventana principal de Fox visible?
Cuando se usa este tipo de forms se suele ocultar la ventana principal de Fox (_screen), poniendo un SCREEN=OFF en el CONFIG.FPW que debe ir incluido en el proyecto.

[Germán Montini]

Hola Fernando, lo que sucede es que la linea  _screen.Visible = .f. la saqué porque cuando ejecutaba el procedimiento de ingreso de usuario por mas que estaba en modal, no se detenia el programa a esperar el ingreso de los datos, en CONFIG.FPW, por ahora estoy haciendo el desarrollo del sistema, o sea que cada vez que quiero modificar algo, tendria que salir y modificar esa linea, y calculo que esa linea se pone solo cuando ya se instala el sistema definitivamente en el cliente.

 

 

From: Fernando D. Bozzo

Sent: Friday, June 14, 2013 2:57 AM

To: publice...@googlegroups.com

Subject: Re: [vfp] No de detiene a esperar una clase de tipo modal

[Germán Montini]

Este es de nivel superior, poniendole la propiedad ShowWindow= 2 As Top-Level Form, no se detiene a esperar interactuar con el usuario

[Fernando D. Bozzo]

Germán, vaya mezcla que estás haciendo :)

A ver, vamos por partes:
Para que _SCREEN se oculte cuando ejecutás como EXE y se muestre cuando ejecutás en Desarrollo, lo que se hace es algo que ya te comente antes, pero que creo que no entendiste bien. La cosa es así, imaginate que tenés esta estructura típica de proyecto:

Dir.Raiz\            ==> Normalmente aquí está el PJX/PJT y el PRG principal (llamémoslo MAIN.PRG)
         \forms      ==> Todos los forms (SCX/SCT)
         \clases     ==> Todas las librerías de clases (VCX/VCT)
         \prgs       ==> Todos los PRG
         \include    ==> Todos los archivos ".H" o también llamados "archivos INCLUDE"
         \config     ==> El CONFIG.FPW
         \datos      ==> Todos los datos (DBF, CDX, DBC, etc)
         \reports    ==> Todos los rpeortes (FRX/FRT)
         \labels     ==> Todos los archivos de etiquetas, si usás (LBX/LBT)


Te marqué en rojo el subdirectorio donde deberías poner tu CONFIG.FPW. Poniéndolo aquí y referenciándolo dentro del proyecto, lográs que se ejecute solo cuando hacés el EXE y que no se ejecute cuando ejecutás en Desarrollo.

El contenido del CONFIG.FPW, cuando trabajás con formularios de nivel superior, suele ser este:

SCREEN=OFF
RESOURCE=OFF

Luego, el hecho de que cuando cerrás el formulario hijo te aparezca la pantalla principal (_SCREEN) solo puede pasarte en Desarrollo, y no debieras tener ningún _SCREEN.VISIBLE=LoQueSea en ningún sitio, ya que el CONFIG.FPW lo tiene.

[Germán Montini]

Gracias Fernando, ahora te entendí mejor, o sea que ahora que estoy desarrollando y probando, no me tiene que importar que no vuelve al form que lo llamó y me aparece la pantalla de visual foxpro, cuando se esté ejecutando el exe, y esté el config.fpw, ahi volverá el foco al form que lo llamó.

 

Germán Montini 

 

 

From: Fernando D. Bozzo

Sent: Friday, June 14, 2013 2:11 PM

To: publice...@googlegroups.com

Subject: Re: [vfp] No de detiene a esperar una clase de tipo modal

[Fernando D. Bozzo]

Exacto! Y una cosa muy importante, el directorio CONFIG es el unico que no debe estar en el path.

Tu path deberia estar configurado asi:

SET PATH TO forms;clases;prgs;include;datos;reports;labels

Este tipo de PATH se llama RELATIVO, y buscara los componentes en los subdirectorios indicados respecto del directorio actual. Lo bueno de este PATH, es que lo podes usar en cualquier aplicacion, y siempre va buscar los componentes en sus respectivos subdirectorios, ademas de convertir a tu aplicacion en desarrollo en portable, ya que la podes mover a otro directorio sin cambiar nada.

Saludos.-

[Germán Montini]

Muchas gracias Fernando, pero una consulta mas, cuando genere el exe, como hago para que me busque el config.fpw, ya que no va a estar en la carpeta raiz del sistema, o en ese momento lo muevo a dicha carpeta.

 

Saludos

 

Germán Montini

 

From: Fernando D. Bozzo

Sent: Saturday, June 15, 2013 6:12 AM

To: publice...@googlegroups.com

Subject: Re: [vfp] No de detiene a esperar una clase de tipo modal

[Ricardo Pina]

Hola German

 

Si el archivo config.fpw lo incluyes en el proyecto al generar el exe, ya no es necesario tenerlo en la carpeta.

 

Saludos

--

            

                   Ricardo Pina

Desarrollo y Servicios Informáticos

                  Profesionales
               www.dsip.com.ar

 

 

[Fernando D. Bozzo]

Hola German, al incluir el archivo CONFIG.FPW en el proyecto y generar el EXE, Fox buscará ese archivo dentro del EXE cuando se ejecute, y ese es el truco que permite que en desarrollo permite que el CONFIG no se ejecute para que puedas depurar (porque al no estar en el path, no lo encuentra), y que al ejecutar el EXE si lo encuentre (dentro de él).

Saludos!