none
Paso de datos de un form a otro form.

    Pregunta

  • Tengo un formulario que llama a otro con form2.showdialog, deseo que el form2 devuelva los valores a traves de unas variables públicas ya definidas y continuar con la linea de codigo en el form1 es decir:

    en el boton coloco:

    var1=""

    var2=""

    form2.showdialog() aqui lleno esas dos variables var1 y var2

    if var1="01" then

      form8.show

      me.hide

    else

        if var2="25" then

           var2=""

       endif

    endif

    Cuendo realizo esto, simplemente consigo que las variables no han cambiado su valor, es decir aun estan en blanco ambas. Alguien me puede ayudar. Gracias.

     

     

    domingo, 13 de junio de 2010 3:12

Respuestas

  • "Jimpares" escribió:

    > Tengo un formulario que llama a otro con form2.showdialog,

    Hola:

    Esa manera de llamar a un formulario mediante su nombre para que éste se muestre, viene del pasado, de los años de Visual Basic clásico, y que se introdujo en Visual Basic 2005, quizás para que los programadores de Visual Basic 6.0 se sintieran "más cómodos" con Visual Basic .NET. En mi opinión personal, es una manera equivocada de trabajar con formularios, porque un formulario es una clase más de las tantas que existen en el marco de trabajo de .NET, por tanto, hay que trabajar con ellos como se trabaja con cualquier otra clase distinta: declarando una variable objeto del tipo del formulario que se trate, y creando una nueva instancia para poder utilizarla.

    Por ejemplo, si deseas abrir de manera modal el formulario llamado Form2, actuarías de la siguiente manera:

        Dim frm As New Form2()

        frm.ShowDialog()

    > deseo que el form2 devuelva los valores a traves de unas variables
    > públicas ya definidas y continuar con la linea de codigo en el form1

    Tampoco tienes por qué tener declaradas variables públicas o globales a tu proyecto para lo que pretendes hacer u obtener, porque también se trata de una reminiscencia del pasado.

    Como te he comentado antes, un formulario es una clase, que como tal, puede tener una interfaz pública y privada, entendiendo como interfaz las propiedades, métodos y eventos de las que dispone la clase.

    Dentro de esa interfaz pública, tú puedes definir las propiedades y métodos que creas conveniente para poder llamarlos a través de la variable objeto que referencia al formulario, la variable «frm» utilizada en el ejemplo anterior.

    Como dices que deseas que Form2 te devuelva el valor de las variables «Var1» y «Var2», se supone que es en éste formulario donde se trabaja con dichas variables. Si es así, lo correcto desde un punto de vista de programación orientada a objetos, es definir un par de Propiedades públicas (Public) o amigables (Friend) dentro de la clase Form2.

    Dentro de la clase Form2 añadirías dos propiedades públicas:

    Public Class Form2

        ' Campos privados de la clase
        '
        Private m_var1 As String
        Private m_var2 As String

        ' Definimos dos propiedades públicas
        '
        Public Property Var1 As String
            Get
                Return m_var1
            End Get
            Set(ByVal value As String)
                m_var1 = value
            End Set
        End Property

        Public Property Var2 As String
            Get
                Return m_var2
            End Get
            Set(ByVal value As String)
                m_var2 = value
            End Set
        End Property

    End Class

    Observa que a nivel de la clase Form2 hay definidos dos campos, «m_var1» y «m_var2», que sería con los que trabajaría internamente la clase Form2. Cuando desde otro formulario cualquiera de tu aplicación, por ejemplo Form1, desees obtener los valores de esos campos internos de Form2, lo harías a través de las propiedades públicas de la clase, es decir, efectuando una llamada a las propiedades «Var1» y «Var2».

    En definitiva, para mostrar el formulario Form2 y obtener el valor de las propiedades definidas, lo harías así:

            ' Definimos e inicializamos la variable objeto
            '
            Dim frm As New Form2()

            ' Mostramos el formulario de manera modal
            '
            frm.ShowDialog()

            ' El formulario se ha cerrado; comprobamos
            ' el valor de sus propiedades.
            '
            If (frm.Var1 = "01") Then

                ' Acciones cuando el valor de la propiedad sea "01"

            ElseIf (frm.Var2 = "25") Then

                ' Acciones cuando el valor de la  propiedad sea "25"

            End If

            ' Destruimos el formulario modal
            '
            frm.Dispose()

    > Cuendo realizo esto, simplemente consigo que las variables no han
    > cambiado su valor, es decir aun estan en blanco ambas.

    Cuando se trabaja con variables globales al proyecto, lo único que se puede obtener son problemas y dolores de cabeza, porque puede suceder que dichas variables no se hayan inicializado correctamente, o se hayan modificado su valores en otra parte de tu proyecto, con lo cual es difícil saber dónde se encuentra el problema.

    Un consejo: si no te quieres atiborrar de aspirinas y otros analgésicos, define propiedades públicas en las clases Form en lugar de trabajar con variables globales a tu proyecto. Te hará ver las cosas de otra manera muy diferente. :-)

    Un saludo

     


    Enrique Martínez [MS MVP - VB]
    domingo, 13 de junio de 2010 6:13
  • "Don_Hard" escribió:

    > lo digo por que una nueva instancia se supone que
    > consume mas memoria (pues con solo show() se muestra
    >

    Amigo, cuando se llama al método «Show» o «ShowDialog» es porque se entiende que se desea abrir un formulario. Si no es ese el motivo, ¿para qué llamar entonces al método «Show» o «ShoWDialog».

    Y referente a que "consumen más memoria", todo dependerá de los controles de usuario que tenga el formulario, así como de las variables objeto que tengas declaradas dentro del mismo. Si tienes 200 controles de usuario, puede ser que notes cierto consumo de memoria, pero cuando se cierre el formulario, todo se destruirá cuando se llame a su método «Dispose», para que las variables objeto y controles queden a disposición del «recolector de elementos no utilizados», que automáticamente se pondrá en marcha cuando estime que no hay recursos disponibles o quedan pocos.


    > eso deja claro que la aplicacion al arrancar crea
    > todos los form que diseñaste)

    Me parece a mí que no es así. Los formularios, que son CLASES QUE HEREDAN DE SYSTEM.WINDOWS.FORMS.FORM, se crean en tiempo de diseño, como cualquier otra clase que hayas creado en tu proyecto. En tiempo de ejecución no se crea ningún formulario; simplemente se crea una nueva instancia de la clase de formulario concreto, y se muestra, porque nosotros queremos que se muestre, si no, ¿para qué "leches" queremos tener formularios en nuestra aplicación de Windows Forms? :-))

    > Para el pase de datos de un Form a otro, tenes varias opciones,
    > como las "propiedades, funcione y procesos" ubicados en un modulo
    > y hasta la sencilla escritura de un "setting de string" de nivel
    > de usuario, lo prove y funciona, cada dia me sorprendo mas de las
    > capacidades de vs

    ¡Si funcionar, funciona! Ahora, ¿es esa la mejor manera de trabajar de una manera orientada a objeto? Me parece a mí que no. Pero como suelo decir con frecuencia, «para gustos están los colores». :-))

    Un saludo

     


    Enrique Martínez [MS MVP - VB]
    martes, 29 de junio de 2010 8:57

Todas las respuestas

  • Debería de funcionar simplemente declarando como publica la variable en el primer formulario

    Public Var1 As Integer

    y haciendo referencia a el desde el formulario 2 de la siguiente manera

    Form1.Var1 = TextBox1.Text ( aqui le asignas el valor)

    Ahora si quieres que su ámbito sea global simplemente decláralo en un modulo, de esta manera no tendrás que hacer referencia al form que lo contenga y podrás asignar el valor en cualquier parte

    Var1 = TextBox1.Text (aquí le asignas el valor)

    Una recomendación, define tus variables según su contenido para evitar sorpresas a la hora de comparaciones u ordenamientos

     


    Saludos ... Morgan 8-)
    domingo, 13 de junio de 2010 3:37
  • hola

    no aconsejaria usar variables publicas para pasar informacion entre formularios, se tornan algo impredecibles de usar porque al estar globales cualqueira pdorias accederlas

    te recomendaria le des una mirada a este link

    Comunicar formularios de forma desacoplada

    alli explico como comunicar formaularios por mede del uso de interfaces que permitan que al retornar la informacion con el form que invoca al form hijo

     

    igualmente solo para sacar de ducas cuando dices: en el boton coloco: var1="" var2=""

    esa asigancion de "" a las variables lo haces en rl form2 ? si es asi queda mas que claro de proque en el toro form no hay datos, no estas asignado nada a esa variables globales

     

    despues comentas "form2.showdialog() aqui lleno esas dos variables var1 y var2 ", en el ShowDialog no no puedes llenar las variables ese es un metodo, deberias asignarlas enen algun evento de algun boton y luego hacer el ShowDialog

     

    te dejo otro link que por ahi podrias ser de utilidad

    [WinForms] – Pasaje de información formulario hijo

    en este se pasa informacion entre el form padre y el hijo que abre, por ahi es este el tipod e comunicacion que podrias usar

    como veras segun el sentido de comunciacion entre los form cambia la tecnica que debe aplicarse

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    domingo, 13 de junio de 2010 4:28
  • "Jimpares" escribió:

    > Tengo un formulario que llama a otro con form2.showdialog,

    Hola:

    Esa manera de llamar a un formulario mediante su nombre para que éste se muestre, viene del pasado, de los años de Visual Basic clásico, y que se introdujo en Visual Basic 2005, quizás para que los programadores de Visual Basic 6.0 se sintieran "más cómodos" con Visual Basic .NET. En mi opinión personal, es una manera equivocada de trabajar con formularios, porque un formulario es una clase más de las tantas que existen en el marco de trabajo de .NET, por tanto, hay que trabajar con ellos como se trabaja con cualquier otra clase distinta: declarando una variable objeto del tipo del formulario que se trate, y creando una nueva instancia para poder utilizarla.

    Por ejemplo, si deseas abrir de manera modal el formulario llamado Form2, actuarías de la siguiente manera:

        Dim frm As New Form2()

        frm.ShowDialog()

    > deseo que el form2 devuelva los valores a traves de unas variables
    > públicas ya definidas y continuar con la linea de codigo en el form1

    Tampoco tienes por qué tener declaradas variables públicas o globales a tu proyecto para lo que pretendes hacer u obtener, porque también se trata de una reminiscencia del pasado.

    Como te he comentado antes, un formulario es una clase, que como tal, puede tener una interfaz pública y privada, entendiendo como interfaz las propiedades, métodos y eventos de las que dispone la clase.

    Dentro de esa interfaz pública, tú puedes definir las propiedades y métodos que creas conveniente para poder llamarlos a través de la variable objeto que referencia al formulario, la variable «frm» utilizada en el ejemplo anterior.

    Como dices que deseas que Form2 te devuelva el valor de las variables «Var1» y «Var2», se supone que es en éste formulario donde se trabaja con dichas variables. Si es así, lo correcto desde un punto de vista de programación orientada a objetos, es definir un par de Propiedades públicas (Public) o amigables (Friend) dentro de la clase Form2.

    Dentro de la clase Form2 añadirías dos propiedades públicas:

    Public Class Form2

        ' Campos privados de la clase
        '
        Private m_var1 As String
        Private m_var2 As String

        ' Definimos dos propiedades públicas
        '
        Public Property Var1 As String
            Get
                Return m_var1
            End Get
            Set(ByVal value As String)
                m_var1 = value
            End Set
        End Property

        Public Property Var2 As String
            Get
                Return m_var2
            End Get
            Set(ByVal value As String)
                m_var2 = value
            End Set
        End Property

    End Class

    Observa que a nivel de la clase Form2 hay definidos dos campos, «m_var1» y «m_var2», que sería con los que trabajaría internamente la clase Form2. Cuando desde otro formulario cualquiera de tu aplicación, por ejemplo Form1, desees obtener los valores de esos campos internos de Form2, lo harías a través de las propiedades públicas de la clase, es decir, efectuando una llamada a las propiedades «Var1» y «Var2».

    En definitiva, para mostrar el formulario Form2 y obtener el valor de las propiedades definidas, lo harías así:

            ' Definimos e inicializamos la variable objeto
            '
            Dim frm As New Form2()

            ' Mostramos el formulario de manera modal
            '
            frm.ShowDialog()

            ' El formulario se ha cerrado; comprobamos
            ' el valor de sus propiedades.
            '
            If (frm.Var1 = "01") Then

                ' Acciones cuando el valor de la propiedad sea "01"

            ElseIf (frm.Var2 = "25") Then

                ' Acciones cuando el valor de la  propiedad sea "25"

            End If

            ' Destruimos el formulario modal
            '
            frm.Dispose()

    > Cuendo realizo esto, simplemente consigo que las variables no han
    > cambiado su valor, es decir aun estan en blanco ambas.

    Cuando se trabaja con variables globales al proyecto, lo único que se puede obtener son problemas y dolores de cabeza, porque puede suceder que dichas variables no se hayan inicializado correctamente, o se hayan modificado su valores en otra parte de tu proyecto, con lo cual es difícil saber dónde se encuentra el problema.

    Un consejo: si no te quieres atiborrar de aspirinas y otros analgésicos, define propiedades públicas en las clases Form en lugar de trabajar con variables globales a tu proyecto. Te hará ver las cosas de otra manera muy diferente. :-)

    Un saludo

     


    Enrique Martínez [MS MVP - VB]
    domingo, 13 de junio de 2010 6:13
  • En mi corta experiencia aprendi a la fuerza que dispones de varios modos ya que tu ingenio es el que dicta las posibilidades (gracias vs), y como dice MorganCun, si podes pasarle directamente si no es algo privado como pass, mientras que no se cierre el form1 no tenes por que complicarte la vida, menos si sos nuevo, como yo :)

    Otro metodo novato es guardar en un archivo de texto, y leerlo desde donde sea necesario, este metodo tiene sus ventajas, podes conservar el dato aun si cerras el form y la aplicacion entera, sirve como memoria pos reinicio y como archivo de configuracion improvisado ja.

    Y desde luego las propiedades que aunque se borran con la muerte de la aplicacion, son muy utiles. Bueno espero ayude saludos.-

    lunes, 14 de junio de 2010 5:42
  • Gracias...

     

    jajaja buen analisis.

    martes, 29 de junio de 2010 5:34
  • Me gusta la idea!!!

    Gracias

    martes, 29 de junio de 2010 5:35
  • Con todo respeto y con el solo fin de unirme a la charla, doy mi opinion, creo que es un modo, no solo adecuado sino inequivoco de utilizar el potencial de vs, (empese a aprender con .net de "6" ni idea), lo digo por que una nueva instancia se supone que consume mas memoria (pues con solo show() se muestra eso deja claro que la aplicacion al arrancar crea todos los form que diseñaste) y aunque vs y te crea exes muy pequeños comen memoria que da calambre, yo esperaba que no demandaran tata memoria al ejecutarse y que fuecen mas livianos, pero me sorprendi de lo pesados que pueden llegar a ser.

     

    Para el pase de datos de un Form a otro, tenes varias opciones, como las "propiedades, funcione y procesos" ubicados en un modulo y hasta la sencilla escritura de un "setting de string" de nivel de usuario, lo prove y funciona, cada dia me sorprendo mas de las capacidades de vs, SALUDOS A TODOS y a no ofenderse que de esa forma no se puede dialogar.

    martes, 29 de junio de 2010 5:55
  • "Don_Hard" escribió:

    > lo digo por que una nueva instancia se supone que
    > consume mas memoria (pues con solo show() se muestra
    >

    Amigo, cuando se llama al método «Show» o «ShowDialog» es porque se entiende que se desea abrir un formulario. Si no es ese el motivo, ¿para qué llamar entonces al método «Show» o «ShoWDialog».

    Y referente a que "consumen más memoria", todo dependerá de los controles de usuario que tenga el formulario, así como de las variables objeto que tengas declaradas dentro del mismo. Si tienes 200 controles de usuario, puede ser que notes cierto consumo de memoria, pero cuando se cierre el formulario, todo se destruirá cuando se llame a su método «Dispose», para que las variables objeto y controles queden a disposición del «recolector de elementos no utilizados», que automáticamente se pondrá en marcha cuando estime que no hay recursos disponibles o quedan pocos.


    > eso deja claro que la aplicacion al arrancar crea
    > todos los form que diseñaste)

    Me parece a mí que no es así. Los formularios, que son CLASES QUE HEREDAN DE SYSTEM.WINDOWS.FORMS.FORM, se crean en tiempo de diseño, como cualquier otra clase que hayas creado en tu proyecto. En tiempo de ejecución no se crea ningún formulario; simplemente se crea una nueva instancia de la clase de formulario concreto, y se muestra, porque nosotros queremos que se muestre, si no, ¿para qué "leches" queremos tener formularios en nuestra aplicación de Windows Forms? :-))

    > Para el pase de datos de un Form a otro, tenes varias opciones,
    > como las "propiedades, funcione y procesos" ubicados en un modulo
    > y hasta la sencilla escritura de un "setting de string" de nivel
    > de usuario, lo prove y funciona, cada dia me sorprendo mas de las
    > capacidades de vs

    ¡Si funcionar, funciona! Ahora, ¿es esa la mejor manera de trabajar de una manera orientada a objeto? Me parece a mí que no. Pero como suelo decir con frecuencia, «para gustos están los colores». :-))

    Un saludo

     


    Enrique Martínez [MS MVP - VB]
    martes, 29 de junio de 2010 8:57
  • Apreciado señor:

    Agradezco mucho su ilustracion. Yo soy un novato y veo con mucha logica y oportunidad tu enseñanza. Imaginar cada cosa como un objeto me tomará algún tiempo pero veo que es la mejor manera de sacar provecho a la herramienta.

    Muchas gracias

     

    viernes, 08 de octubre de 2010 0:21
  • "Armandini7" escribió:

    > Agradezco mucho su ilustracion. Yo soy un novato y veo con mucha
    > logica y oportunidad tu enseñanza. Imaginar cada cosa como un
    > objeto me tomará algún tiempo pero veo que es la mejor manera
    > de sacar provecho a la herramienta.

    Quizás te pueda ser de utilidad lo que explico en el siguiente artículo:

    Cómo pasar datos a un formulario

    Un saludo


    Enrique Martínez [MS MVP - VB]
    viernes, 08 de octubre de 2010 13:24