Pasar parametro desde un formulario a otro

[PETACA]

Hola a todos. Tengo un boton en donde en el evento click llamo a otro
form asi: do form form2 with nCodigo, donde nCodigo es el codigo de un
cliente. En form2 en el evento init hago:
PARAMETERS nCod
THIS.nCodigo = nCod
Nunca recibo un valor en nCod.
No es un set de formularios y ambos tienen la propiedad ShowWindow = 1
y WindowsType= 1
Espero alguien pueda ayudarme.

Saludos y gracias

[Miguel Canchas]

es LPARAMETERS

y tu formulario debe de ser Modal.

MK

[Moises Daniel Vilchez Tello]

puedes utilizar una coleccion para evitar as variables publicas

El 8 de julio de 2010 15:53, Miguel Canchas <mcan...@tracusape.com> escribió:

es LPARAMETERS

y tu formulario debe de ser Modal.

MK

----- Original Message ----- From: "PETACA" <fabian...@arnet.com.ar>

To: "Comunidad de Visual Foxpro en Español" <publice...@googlegroups.com>

Sent: Thursday, July 08, 2010 3:52 PM
Subject: [vfp] Pasar parametro desde un formulario a otro

Hola a todos. Tengo un boton en donde en el evento click llamo a otro
form asi: do form form2 with nCodigo, donde nCodigo es el codigo de un
cliente. En form2 en el evento init hago:
PARAMETERS nCod
THIS.nCodigo = nCod
Nunca recibo un valor en nCod.
No es un set de formularios y ambos tienen la propiedad ShowWindow = 1
y WindowsType= 1
Espero alguien pueda ayudarme.

Saludos y gracias

--
Moises Vilchez Tello
Soporte Tecnico de HW & SW

[Hitiel Hernández]

no te hagas bolas, crea una variable pública y allí guarda el código de tu cliente, luego

en el otro formulario lo recuperas.

Es una salida fácil

[David Gerardo Dominguez]

Hola Hitiel, respeto tu opinión, pero en nuesrtras aplicaciones debemos evitar utilizar variables públicas en todo momento, entre menos tengamos es mejor.

 

Saludos

[Richard Gaviria]

Creo que deberíamos incluir los nombres o los nicks para identificarnos.
 
Saludos.
 
Richard D. Gaviria
 

---

Date: Tue, 13 Jul 2010 10:10:03 -0600
Subject: Re: [vfp] Pasar parametro desde un formulario a otro
From: hiti...@gmail.com
To: publice...@googlegroups.com

[Luis Mata]

Pues esta bien lo que haces a menos que tengas una variable declarada y una tabla que tenga un campo con el mismo nombre, revisa eso.

 

Luis

[Richard Gaviria]

Bueno, el tema con las variables en general, sobre todo las públicas, la cuestión radica en que cuando se involucra en varias partes de un proceso, cambian constantemente   y no tenemos un adecuado control en la inicialización y/o cambio de valor. Yo por lo general uso variables públicas cuando necesito un retorno de valor de un formulario, como dice David es mejor pasar como parámetro el valor hacia otro formulario.
 
Saludos.
 
Richard d. Gaviria
 

---

Date: Tue, 13 Jul 2010 11:16:22 -0500
Subject: Re: [vfp] Pasar parametro desde un formulario a otro
From: davidge...@gmail.com
To: publice...@googlegroups.com

[Luis Mata]

La idea de esa variale publica es que no cambie por Ejm:

 

- Una conexion a BD

- Un impuesto a las ventas

- Tipo de cambio de moneda

- Nombre de usuario logueado

- Ruc de la empresa

- Nombre de la empresa

- Direccion de la empresa

- Telefonos

 

Claro que tambien de declararlas las puedes tener en una tabla.

 

Luis Mata

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

From: Richard Gaviria

To: publice...@googlegroups.com

[Luis Maria Guayan]

Lo que haces es correcto, lo único que tendrias que hacer es comprobar si nCodigo tiene un valor antes de llamar y si en el Init recibes el valor en nCod.

Ej, al llamar en formulario

MESSAGEBOX(nCodigo,0,"Parametro enviado")
do form form2 with nCodigo

Ej, en el Init del formulario

LPARAMETERS nCod
MESSAGEBOX(nCod,0,"Parametro recibido")

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

 

[Walter R. Ojeda Valiente]

Usar una variable pública se justifica solamente y únicamente si se le asignará su valor en un solo lugar, aunque se la pueda utilizar en muchos otros lugares. Las variables públicas pueden causar problemas inmensos cuando sus valores son asignados en distintos lugares de la aplicación (funciones, rutinas, clases, etc.) porque resulta complicado saber que valor tiene actualmente la susodicha en este momento y en este lugar, pero pueden resultar útiles si la asignación se realiza una sola vez (lo mejor: al principio de la aplicación).

Por ejemplo, yo utilizo la variable pública hSQL para la conexión a la Base de Datos. Así, puedo utilizarla cuando la necesite sin necesidad de pasarla como argumento de alguna función o procedimiento. Pero hSQL obtiene su valor al principio de la aplicación, su valor nunca cambia después.

Saludos.

Walter.

La idea de esa variale publica es que no cambie por Ejm:

 

- Una conexion a BD

- Un impuesto a las ventas

- Tipo de cambio de moneda

- Nombre de usuario logueado

- Ruc de la empresa

- Nombre de la empresa

- Direccion de la empresa

- Telefonos

 

Claro que tambien de declararlas las puedes tener en una tabla.

 

Luis Mata

---

Hotmail: Trusted email with powerful SPAM protection. Sign up now.

[Luis Mata]

Exacto, si las variables son muy usadas y las tienes que declarar a cada rato en cada form, puede crear una tabla de control la abres y las vas leyendo.

Otro problema que encontre al usar variables publicas a cada rato es que las tenia que estar declarando a cada rato por cada vez que queria probar el form y era molesto.

 

Una tabla de control con los datos que mas utilizas y solucionado.

 

Luis

 

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

From: Walter R. Ojeda Valiente

To: publice...@googlegroups.com

Sent: Tuesday, July 13, 2010 1:44 PM

Subject: RE: [vfp] Pasar parametro desde un formulario a otro

[Roberto Olivas Mendoza]

Les recomiendo que busquen en google “Programación Orientada a Objetos con Visual FoxPro”, pues todo lo que proponen es seguir programando a la vieja usanza XBase. Creanme, con eso desaprovechan totalmente la potencia de Visual FoxPro.

 

Si desean tener acceso a ciertos datos durante toda el tiempo de uso de la aplicación, mejor creen propiedades en el objeto _Screen, pues de esta manera cumplen con el paradigma de la programación orientada a objetos.

 

Por ejemplo:

 

Al iniciar la aplicación pueden declarar:

 

_Screen.AddProperty(“hSQL”,0)

 

Y después utilizar esta propiedad para guardar el manejador de conexión para un servidor SQL. Con esto el valor del manejador de conexión estará disponible para toda la aplicación.

[Walter R. Ojeda Valiente]

Hola Roberto

Es cierto lo que dices, pero es más largo, escribir simplemente hSQL es más corto y muy sencillo.

Saludos.

Walter

[Roberto Olivas Mendoza]

Posiblemente, pero te garantizo que si cumples con el paradigma de Orientación a Objetos a la larga te va a resultar menos laborioso y más sencillo llevar tu código a otra herramienta de desarrollo, cuando la tecnología te obligue a ello. Ninguna herramienta de desarrollo es eterna y por lo tanto debemos tomar en cuenta el costo que implica reescribir todo nuestro código por no tratar de cumplir con paradigmas establecidos hasta en la comunidad internacional.

 

En el caso de nuestros productos, al cumplir con el paradigma OOP nos hemos ahorrado una cantidad inmensa de tiempo y esfuerzo al mover nuestras aplicaciones a C# (.NET), inclusive nos es posible moverlas a Java con un costo 50% menor al hecho de tener que reescribir todo el código.

[wchalito]

Saludos,

1.- Muy aparte del MODAL fijate si el formulario 2 en su propiedad
DATASESSION es 1: Sesión predeterminada de datos.
2.- Como dicen los colegas, está correcto lo que haces y deberías
fijarte si nCodigo tiene algún valor antes de pasarlo.
3.- A parte de esta forma de pasar parámetros hay otra en la cual
pasas como parámetro todo el objeto, es decir todo el formulario de
esta forma:

DO FORM Form2 WITH nCodigo, ThisForm

En el INIT del FORM2 lo recibes de esta menara:

PARAMETERS nCod, cThisForm
ThisForm.oThisForm = cThisForm && Creas una propiedad oThisForm para
recibir el objeto enviado.

Es desde este momento en donde desde el FORM2 puedes tener control del
FORM1 sin salir del FORM2, como por ejemplo: Si tienes un objeto TEXT
en el FORM1 llamado txtDes_Cliente le puedes asignar un valor desde el
FORM2 de la siguiente manera:

ThisForm.oThisForm.txtDes_Cliente.Value =
ThisForm.txtDes_Cliente.Value

O refrescar un grid en el FORM1 desde el FORM2:

ThisForm.oThisForm.Grid1.Refresh

Espero halla sido claro mi ejemplo.

Saludos.

Chalito
LIMA - PERU

[Luis Mata]

No siempre la teoria es lo requerido en la practica hay cosas que se deben de hacer de otra forma si es mas rapido.

porque darme una tremenda vuelta para llegar a los mismo. ¿Porque solo lo dice la teoria?

[Roberto Olivas Mendoza]

No es porque lo dice la teoría. Es porque esa “teoría” ha sido fundamentada por personas que tienen décadas de experiencia en el desarrollo de software, no sólo en Visual FoxPro, sino en muchas herramientas de desarrollo y está comprobada con resultados. Los desarrolladores de software no buscamos la “rapidez” sino la funcionalidad y la eficiencia. Nuestro trabajo consiste en proporcionarle la “rapidez” a los usuarios.

 

Este razonamiento nos ha llevado aquí en México a desarrollar un modelo de calidad para la Industria del Software, el cual persigue precisamente eso: funcionalidad y eficiencia basados en una metodología. Este modelo se llama MOPROSOFT.

[Luis Mata]

El modelo de desarrollar no afecta al usuario mi estimado sino al desarrollador si para mostrar un Msg le das la vuelta al mundo y yo lo muestro directamente el usuario va a ver el resultado y ni va a saber la forma de diseño.

Para tener un mejor control sobre el proyecto y encontrar de forma rapida cualquier error general del sistema va depender como hayas planificado tu software y mucha otras cosas mas.

[Roberto Olivas Mendoza]

Pues discúlpame por hacerle caso a personas que como Desarrolladores e Ingenieros de Computación están a varios años luz de distancia de nosotros. Es muy probable que todos ellos estén equivocados y que seas tú el que tenga la razón.

[wchalito]

Disculpen,

Pero alguien se acuerda de PETACA quien fue EL o LA que lanzó la
PARADIGMATICA problemática de pasar parámetros entre
formularios????... al menos que nos indique si llegó a solucionar su
problema, les sirvió de algo nuestras sugerencias, etc, etc, etc. Al
menos una señal de vida indicando que si quiera ha leído nuestras
recomendaciones.

Y muchachos MATA y OLIVAS, todos buscamos siempre la perfección en
nuestros sistemas, creánme que cuando termino un proyecto, pasado el
tiempo sigo metiéndole mano mejorándolo y son esos instantes en donde
me doy cuenta que lo pude hacer mejor, veo procesos en donde me hice
muchas "bolas" para llegar a un fín y lo pude haber hecho mas corto y
al hacerlo, me complasco de que al menos habré reducido milésimas de
segundos en dichos proceso, solo eso, por que al final siempre se
llega al mismo resultado.

Atte.

Chalito
LIMA - PERU

On 15 jul, 18:36, "Roberto Olivas Mendoza"

<rolivasmend...@megared.net.mx> wrote:
> Pues discúlpame por hacerle caso a personas que como Desarrolladores e
> Ingenieros de Computación están a varios años luz de distancia de nosotros.
> Es muy probable que todos ellos estén equivocados y que seas tú el que tenga
> la razón.
>
> De: publice...@googlegroups.com
> [mailto:publice...@googlegroups.com] En nombre de Luis Mata
> Enviado el: Miércoles, 14 de Julio de 2010 08:23 a.m.
> Para: publice...@googlegroups.com
> Asunto: Re: [vfp] Pasar parametro desde un formulario a otro
>
> El modelo de desarrollar no afecta al usuario mi estimado sino al
> desarrollador si para mostrar un Msg le das la vuelta al mundo y yo lo
> muestro directamente el usuario va a ver el resultado y ni va a saber la
> forma de diseño.
>
> Para tener un mejor control sobre el proyecto y encontrar de forma rapida
> cualquier error general del sistema va depender como hayas planificado tu
> software y mucha otras cosas mas.
>
> Luis
>
>
>
> ----- Original Message -----
>

> From: Roberto Olivas Mendoza <mailto:rolivasmend...@megared.net.mx>  
>
> To: publice...@googlegroups.com
>
> Sent: Tuesday, July 13, 2010 5:36 PM
>
> Subject: RE: [vfp] Pasar parametro desde un formulario a otro
>
> No es porque lo dice la teoría. Es porque esa “teoría” ha sido fundamentada
> por personas que tienen décadas de experiencia en el desarrollo de software,
> no sólo en Visual FoxPro, sino en muchas herramientas de desarrollo y está
> comprobada con resultados. Los desarrolladores de software no buscamos la
> “rapidez” sino la funcionalidad y la eficiencia. Nuestro trabajo consiste en
> proporcionarle la “rapidez” a los usuarios.
>
> Este razonamiento nos ha llevado aquí en México a desarrollar un modelo de
> calidad para la Industria del Software, el cual persigue precisamente eso:
> funcionalidad y eficiencia basados en una metodología. Este modelo se llama
> MOPROSOFT.
>
> De: publice...@googlegroups.com
> [mailto:publice...@googlegroups.com] En nombre de Luis Mata
> Enviado el: Martes, 13 de Julio de 2010 04:07 p.m.
> Para: publice...@googlegroups.com
> Asunto: Re: [vfp] Pasar parametro desde un formulario a otro
>
> No siempre la teoria es lo requerido en la practica hay cosas que se deben
> de hacer de otra forma si es mas rapido.
>
> porque darme una tremenda vuelta para llegar a los mismo. ¿Porque solo lo
> dice la teoria?
>
> ----- Original Message -----
>

> Hotmail: Trusted email with powerful SPAM protection. Sign up now.

> <https://signup.live.com/signup.aspx?id=60969>  

[Hitiel Hernández]

Buenas noches compañeros foxeros!

Cuando recién el compañero lanzó esta pregunta lo primero que se me vino a la menta fué en publicar una variable, ya mucho le hemos dado vueltas al asunto y la idea pareció "descabellada" y descartada.

Después de analizar el asunto les di la razón, porque yo no lo he usado de esa manera.

La forma en que paso parámetros de un formulario a otro es utilizando el siguiente código en evento click del botón que llamará al otro formulario:

Ej.

             DO FORM imprime WITH "cheques.frx"

en este caso le estoy pasado como parámetro el nombre de un archivo de reportes al otro formulario para que él lo reciba y lo ejecute.

En el evento init del formulario IMPRIME, escribo lo siguiente:

                      LPARAMETER NombreRep

                      thisform.nomrep = NombreRep

y en el botón imprimir siempre de dicho formulario escribo lo siguiente: (este formulario lo utilizo para todos mis reportes)

NomRep = thisform.nomrep

REPO FORM &NomRep  TO PRINTER PROMPT PREVIEW

***** nomrep = método (vacío)

Si alguien lo puede hacer más fácil le ruego que lo haga saber.

gracias

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

[Julio Rossi]

Hitiel, �no has pensado en pasar un objeto en vez de una variable?
De esa manera podr�as pasar al formulario muchos otros datos y uo c�digo
no cambiar�a si hay que enviar otro par�metro el d�a de ma�ana.
Te copio y pego de como lo hago al llamar a un formulario de impresi�n.
De esta forma hasta le paso una referencia al formulario que hace la
llamada por si necesito alg�n valor adicional.

******************************************************************************
* IMPRESION *
******************************************************************************
* PARAMETROS QUE SE ENVIAN *
* ID_CODIGO (DE IMPRESORA EN TTYLPT) SI NO ES LA PREDETERMINADA *
* NUMERO DE COPIAS A IMPRIMIR
* NUMERO DE COPIAS FIJO - POR DEFECTO: NO
* SI SE PERMITE MODIFICAR LA IMPRESORA POR DEFECTO: SI
* TITULO DEL FORMULARIO DE IMPRESION PARA AGREGAR AL TITULO DEL FORMULARIO
* LETRA DEL REPORTE - POR DEFECTO: COURIER NEW
* TAMA�O DE LETRA DEL REPORTE - POR DEFECTO: 10
* ANCHO DEL REPORTE A TRASLADAR A VARIABLE DE SISTEMA _RMARGIN
* NOMBRE DEL PROGRAMA ACTUAL
* NOMBRE DE LA FUNCION QUE CREA EL ARCHIVO DE TEXTO - POR DEFECTO:
PL_REPORTE

LOCAL OL_PM AS OBJECT
OL_PM = CREATEOBJECT("EMPTY")
ADDPROPERTY(OL_PM,"P_TTYLPT",CT_CHAR_EMPTY)
ADDPROPERTY(OL_PM,"P_COPIAS",1)
ADDPROPERTY(OL_PM,"P_NCOPIASF",.F.)
ADDPROPERTY(OL_PM,"P_MODPRN",.T.)
ADDPROPERTY(OL_PM,"P_TITULO","Listado de Comprobantes por estado")
ADDPROPERTY(OL_PM,"P_FONT",CT_CHAR_EMPTY)
ADDPROPERTY(OL_PM,"P_FONTSIZE",0)
ADDPROPERTY(OL_PM,"P_RMARGIN",171)
ADDPROPERTY(OL_PM,"P_PROGRAM","F_VT_LISCPE")
ADDPROPERTY(OL_PM,"P_DO","M_REPORTE")
ADDPROPERTY(OL_PM,"P_FORM",THISFORM)
ADDPROPERTY(OL_PM,"P_ONPAGE",.T.)

DO FORM F_STPRINT WITH OL_PM

RELEASE OL_PM
******************************************************************************
* FIN IMPRESION *
******************************************************************************
RETURN

En el formulario que es llamado, creo una propiedad para almacenar el
objeto enviado(P_OG) y en el init pongo:

LPARAMETERS OL_PMINIT

* ASIGNA OBJETO (DE PARAMETROS) A PROPIEDAD DEL FORMULARIO *
THISFORM.P_OG = OL_PMINIT

De esta forma tengo todos los par�metros pasados desde el otro
formulario, y a�n una referencia al mismo (en la propiedad P_FORM).
Para hacer referencia a cualquier propiedad, por ejemplo P_TITULO haces:

?? thisform.p_OG.p_titulo.

Espero te sirva.
Un saludo cordial.

Julio Rossi
VFP 9 - SP2

El 16/07/2010 02:56 a.m., Hitiel Hern�ndez escribi�:
> Buenas noches compa�eros foxeros!
>
> Cuando reci�n el compa�ero lanz� esta pregunta lo primero que se me vino
> a la menta fu� en publicar una variable, ya mucho le hemos dado vueltas
> al asunto y la idea pareci� "descabellada" y descartada.
> Despu�s de analizar el asunto les di la raz�n, porque yo no lo he usado
> de esa manera.
>
> La forma en que paso par�metros de un formulario a otro es utilizando el
> siguiente c�digo en evento click del bot�n que llamar� al otro formulario:

> Ej.
> DO FORM imprime WITH "cheques.frx"
>

> en este caso le estoy pasado como par�metro el nombre de un archivo de
> reportes al otro formulario para que �l lo reciba y lo ejecute.

>
> En el evento init del formulario IMPRIME, escribo lo siguiente:
>
> LPARAMETER NombreRep
> thisform.nomrep = NombreRep
>

> y en el bot�n imprimir siempre de dicho formulario escribo lo siguiente:

> (este formulario lo utilizo para todos mis reportes)
>
> NomRep = thisform.nomrep
> REPO FORM &NomRep TO PRINTER PROMPT PREVIEW
>

> ***** nomrep = m�todo (vac�o)
>
> Si alguien lo puede hacer m�s f�cil le ruego que lo haga saber.

> gracias
>
> ------------------------------------------------------------------------------------------------------------------------
>
> El 15 de julio de 2010 21:59, wchalito <wcha...@gmail.com

> <mailto:wcha...@gmail.com>> escribi�:
>
> Disculpen,
>
> Pero alguien se acuerda de PETACA quien fue EL o LA que lanz� la
> PARADIGMATICA problem�tica de pasar par�metros entre
> formularios????... al menos que nos indique si lleg� a solucionar su
> problema, les sirvi� de algo nuestras sugerencias, etc, etc, etc. Al
> menos una se�al de vida indicando que si quiera ha le�do nuestras
> recomendaciones.
>
> Y muchachos MATA y OLIVAS, todos buscamos siempre la perfecci�n en
> nuestros sistemas, cre�nme que cuando termino un proyecto, pasado el
> tiempo sigo meti�ndole mano mejor�ndolo y son esos instantes en donde

> me doy cuenta que lo pude hacer mejor, veo procesos en donde me hice

> muchas "bolas" para llegar a un f�n y lo pude haber hecho mas corto y
> al hacerlo, me complasco de que al menos habr� reducido mil�simas de

> segundos en dichos proceso, solo eso, por que al final siempre se
> llega al mismo resultado.
>
> Atte.
>
> Chalito
> LIMA - PERU
>
> On 15 jul, 18:36, "Roberto Olivas Mendoza"
> <rolivasmend...@megared.net.mx

> <mailto:rolivasmend...@megared.net.mx>> wrote:
> > Pues disc�lpame por hacerle caso a personas que como
> Desarrolladores e
> > Ingenieros de Computaci�n est�n a varios a�os luz de distancia de
> nosotros.
> > Es muy probable que todos ellos est�n equivocados y que seas t�
> el que tenga
> > la raz�n.

> >
> > De: publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>
> > [mailto:publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>] En nombre de Luis Mata
> > Enviado el: Mi�rcoles, 14 de Julio de 2010 08:23 a.m.
> > Para: publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>
> > Asunto: Re: [vfp] Pasar parametro desde un formulario a otro
> >
> > El modelo de desarrollar no afecta al usuario mi estimado sino al
> > desarrollador si para mostrar un Msg le das la vuelta al mundo y
> yo lo
> > muestro directamente el usuario va a ver el resultado y ni va a
> saber la

> > forma de dise�o.

> >
> > Para tener un mejor control sobre el proyecto y encontrar de
> forma rapida
> > cualquier error general del sistema va depender como hayas
> planificado tu
> > software y mucha otras cosas mas.
> >
> > Luis
> >
> >
> >
> > ----- Original Message -----
> >
> > From: Roberto Olivas Mendoza
> <mailto:rolivasmend...@megared.net.mx

> <mailto:rolivasmend...@megared.net.mx>>
> >
> > To: publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>

> >
> > Sent: Tuesday, July 13, 2010 5:36 PM
> >
> > Subject: RE: [vfp] Pasar parametro desde un formulario a otro
> >

> > No es porque lo dice la teor�a. Es porque esa �teor�a� ha sido
> fundamentada
> > por personas que tienen d�cadas de experiencia en el desarrollo
> de software,
> > no s�lo en Visual FoxPro, sino en muchas herramientas de
> desarrollo y est�

> > comprobada con resultados. Los desarrolladores de software no
> buscamos la

> > �rapidez� sino la funcionalidad y la eficiencia. Nuestro trabajo
> consiste en
> > proporcionarle la �rapidez� a los usuarios.
> >
> > Este razonamiento nos ha llevado aqu� en M�xico a desarrollar un

> modelo de
> > calidad para la Industria del Software, el cual persigue
> precisamente eso:

> > funcionalidad y eficiencia basados en una metodolog�a. Este

> modelo se llama
> > MOPROSOFT.
> >
> > De: publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>
> > [mailto:publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>] En nombre de Luis Mata
> > Enviado el: Martes, 13 de Julio de 2010 04:07 p.m.
> > Para: publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>
> > Asunto: Re: [vfp] Pasar parametro desde un formulario a otro
> >
> > No siempre la teoria es lo requerido en la practica hay cosas que
> se deben
> > de hacer de otra forma si es mas rapido.
> >

> > porque darme una tremenda vuelta para llegar a los mismo. �Porque

> solo lo
> > dice la teoria?
> >
> > ----- Original Message -----
> >
> > From: Walter R. Ojeda Valiente <mailto:w...@hotmail.com

> <mailto:w...@hotmail.com>>
> >
> > To: publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>

> >
> > Sent: Tuesday, July 13, 2010 4:08 PM
> >
> > Subject: RE: [vfp] Pasar parametro desde un formulario a otro
> >
> > Hola Roberto
> >

> > Es cierto lo que dices, pero es m�s largo, escribir simplemente
> hSQL es m�s

> > corto y muy sencillo.
> >
> > Saludos.
> >
> > Walter
> >

> > Les recomiendo que busquen en google �Programaci�n Orientada a
> Objetos con
> > Visual FoxPro�, pues todo lo que proponen es seguir programando a

> la vieja
> > usanza XBase. Creanme, con eso desaprovechan totalmente la
> potencia de
> > Visual FoxPro.
> >
> > Si desean tener acceso a ciertos datos durante toda el tiempo de
> uso de la

> > aplicaci�n, mejor creen propiedades en el objeto _Screen, pues de
> esta
> > manera cumplen con el paradigma de la programaci�n orientada a
> objetos.
> >
> > Por ejemplo:
> >
> > Al iniciar la aplicaci�n pueden declarar:
> >
> > _Screen.AddProperty(�hSQL�,0)
> >
> > Y despu�s utilizar esta propiedad para guardar el manejador de
> conexi�n para
> > un servidor SQL. Con esto el valor del manejador de conexi�n estar�
> > disponible para toda la aplicaci�n.

> >
> > De: publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>
> > [mailto:publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>] En nombre de Luis Mata
> > Enviado el: Martes, 13 de Julio de 2010 01:56 p.m.
> > Para: publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>
> > Asunto: Re: [vfp] Pasar parametro desde un formulario a otro
> >
> > Exacto, si las variables son muy usadas y las tienes que declarar
> a cada
> > rato en cada form, puede crear una tabla de control la abres y
> las vas
> > leyendo.
> >
> > Otro problema que encontre al usar variables publicas a cada rato
> es que las
> > tenia que estar declarando a cada rato por cada vez que queria
> probar el
> > form y era molesto.
> >
> > Una tabla de control con los datos que mas utilizas y solucionado.
> >
> > Luis
> >
> > ----- Original Message -----
> >
> > From: Walter R. Ojeda Valiente <mailto:w...@hotmail.com

> <mailto:w...@hotmail.com>>
> >
> > To: publice...@googlegroups.com
> <mailto:publice...@googlegroups.com>

> >
> > Sent: Tuesday, July 13, 2010 1:44 PM
> >
> > Subject: RE: [vfp] Pasar parametro desde un formulario a otro
> >

> > Usar una variable p�blica se justifica solamente y �nicamente si
> se le
> > asignar� su valor en un solo lugar, aunque se la pueda utilizar
> en muchos
> > otros lugares. Las variables p�blicas pueden causar problemas

> inmensos
> > cuando sus valores son asignados en distintos lugares de la

> aplicaci�n

> > (funciones, rutinas, clases, etc.) porque resulta complicado
> saber que valor
> > tiene actualmente la susodicha en este momento y en este lugar,
> pero pueden

> > resultar �tiles si la asignaci�n se realiza una sola vez (lo
> mejor: al
> > principio de la aplicaci�n).
> >
> > Por ejemplo, yo utilizo la variable p�blica hSQL para la conexi�n
> a la Base
> > de Datos. As�, puedo utilizarla cuando la necesite sin necesidad
> de pasarla
> > como argumento de alguna funci�n o procedimiento. Pero hSQL
> obtiene su valor
> > al principio de la aplicaci�n, su valor nunca cambia despu�s.

[Daniel Sánchez]

Yo también aplico el mismo método de pasar un objeto con propiedades así no tengo que pasar muchos parámetros al formulario llamado solo la referencia de la variable ya que los objetos se pasan por referencia y no por valor y hace al código de programa mas eficiente dicho sea de paso.

-- 

Daniel Sánchez Escobar
Investigación y Desarrollo
Reset Software & Sistemas
Móvil 044-949398047
Trujillo - Perú

[Hitiel Hernández]

Gracias, gracias, gracias, muchas gracias

lo tomaré en cuenta ahora mismo

[fputignani]

El tema es un poco viejo, pero lo revivo para no andar abriendo otro
tema por una simple pregunta.

Que diferencia hay, o cual es mejor o peor en cuanto a rendimiento
velocidad y es mejor practica o peor, entre crear una variable global,
o agregar una propiedad nueva a por ejemplo un formulario.



PD: Lo pregunto solo para saber porque me interesa, pero en realidad
estoy tratando de hacer un programita tan sencillo que cualquier cosa
que funque viene bien =)

[Victor E. Torres Tejada]

SI planeas quedarte en VFP hasta el fin de los tiempos, puedes definir

las variables globales al comienzo de tu aplicativo y usarlo desde cualquier

parte de tu aplicacion como siempre, pero si tienes intencion de migrar a

otra herramienta seria un buen ejercicio que trates de poner todas tus

variables globales en algun objeto que puedas instanciar y llamar o agregarlo

en algun otro objeto como un form desde cualquier parte de tu aplicacion,

lo cargas inicialemente de la base de datos y luego las guardas localmente

en la PC (en el registro o en el disco ), hay varias variantes.

Es un buen ejercicio cuando tratamos de hacer lo mismo que hacemos en VFP,

pero en VB.NET o C#. pero si te vas a quedar en VFP sigue con Public XXX

--

Victor E. Torres Tejada

www.o-negocios.com

4216093 - 993290086

 

Buscador de productos       

Envianos tu pedido aqui

[marcelobuenosaires]

Hola

Para evitar variables publicas
lo mejor es utilizar un objeto y cargar las variables en El

Y que mejor objeto que la "pantalla"
ya que... si o si, va estar siempre disponible
en el programa

Asi...

_screen.addProperty("miVar",10)

Ahora, la variable _screen.miVar (que es numerica y vale 10)
esta disponible para ser llamada desde cualquier formulario

Saludos
MarceloBuenosAires
______

Victor E. Torres Tejada escribió:

[Luis Maria Guayan]

En la programación orientada a objetos, no está bien visto utilizar variables globales. en su lugar utiliza propiedades ya sea de tu formulario, o si quieres que esas propiedades estén al alcance de toda tu aplicación, las creas en el objeto _Screen (como te indico Marcelo)

Luis María Guayán
Tucumán, Argentina
_________________________
http://www.PortalFox.com
Nada corre como un zorro
_________________________

[Carlos Miguel FARIAS]

La OOP es buena porque te reduce la redundancia de código (es como cuando normalizas datos). Eso evita que cuando arreglas una función/método (adaptas  o corregís) se hace en un solo punto, probas, si ok, el arreglo se propaga a todos lados.

Las variables globales son útiles si se cargan una sola vez y las usas en muchos lados. Claro está que en muchos lenguajes OO mas puros, no manejan globales en la forma tan simple que hace fox, pero nadie discutir su utilidad y su simplicidad.

Comparto de meterlas en objeto que siempre esta (como el _SCREEN) o que casualmente es una variable global del sistema, pero es una variable global, y los errores de asignación de uso, son siempre las mismas.

Lo bueno del zorro es que te da la libertad de hacerlo "purista" o a lo "bestia", y a veces, conviene ser la bestia, que se queda con la bella!!!

[fputignani]

Muchas gracias gente, ya tengo una idea más clara.
Y me gusto mucho la ultima frase de Carlos =)
Saludos y grax

On 9 sep, 08:26, Carlos Miguel FARIAS <carlosmiguelfar...@gmail.com>
wrote:

> La OOP es buena porque te reduce la redundancia de código (es como cuando
> normalizas datos). Eso evita que cuando arreglas una función/método (adaptas
>  o corregís) se hace en un solo punto, probas, si ok, el arreglo se propaga
> a todos lados.
> Las variables globales son útiles si se cargan una sola vez y las usas en
> muchos lados. Claro está que en muchos lenguajes OO mas puros, no manejan
> globales en la forma tan simple que hace fox, pero nadie discutir su
> utilidad y su simplicidad.
> Comparto de meterlas en objeto que siempre esta (como el _SCREEN) o que
> casualmente es una variable global del sistema, pero es una variable global,
> y los errores de asignación de uso, son siempre las mismas.
> Lo bueno del zorro es que te da la libertad de hacerlo "purista" o a lo
> "bestia", y a veces, conviene ser la bestia, que se queda con la bella!!!
>

> El 9 de septiembre de 2010 13:00, Luis Maria Guayan <luisma...@portalfox.com