Cómo puedo llamar a un formulario desde otro formulario?

Esta pregunta se repite muchas veces por aquí, mira a ver si esto aclara un
poco tu duda:

http://www.microsoft.com/spanish/ms...eForms.asp


Juan Carlos Badiola
MVP - C#

Hola Tristan,

muchas gracias por tu respuesta,

el artículo esta bastante bien, lastima que no haya un conversor de
aplicación de EVB a .NET como hay para VB6. Al final he optado por crear los
formularios como variables públicas desde un modulo, me ha parecido la
solución más sencilla... ya ire contando como va.

Un saludo,
José Luis.

"Tristan" escribió en el mensaje
news:

Esta pregunta se repite muchas veces por aquí, mira a ver si esto aclara

un

poco tu duda:

http://www.microsoft.com/spanish/ms...ces/vbtchW
orkingWithMultipleForms.asp

Juan Carlos Badiola
MVP - C#

Al final he optado por crear los
formularios como variables públicas desde un modulo, me ha parecido la
solución más sencilla

No te lo recomiendo. Creeme. Me parece la peor opción.

La forma de trabajo más similar a VB es la del punto: "¿Cómo trata este
problema el Asistente para actualización?", que es simplemente aplicar el
patrón Singleton. Con solo copiar-pegar las pocas lineas de DefInstance a
las clases de tus formularios, podrás trabajar de la misma en que lo hacías
hasta ahora con vb. Es decir:

Mostrar un form:
Form1.DefInstance.Show()

Modificar uno de sus controles desde cualquier parte de tu aplicación:
Form1.DefInstance.TextBox1.Text = "Texto modificado"

Cerrar un form:
Form1.DefInstance.Close()

Es decir, la única diferencia con VB es que al nombre de la clase Form1,
tendrás que añadir .DefInstance.

Si sigues ese patrón, igual que en VB, cuando muestres un formulario por
segunda vez, no se creará una instancia nueva.

Realmente hacer eso mismo con variables globales no aporta ninguna ventaja,
y si varios inconvenientes, tanto en rendimiento, como de facilidad de
desarrollo y mantenibilidad.

Juan Carlos Badiola
MVP - C#

Buenas Tristan,

antes de decantarme por la opción que te he comentado, a mi tampoco creas
que me hace mucha gracia, había probado la que me comentas ya que también me
parecia la más limpia. Pero no la he podido utilizar porque se ve que el
espacio de nombres que se utiliza no esta disponible en las aplicciones
Smart device... por lo que me deja sin poder usar esta opción. Mi idea
inicial era pasar la aplicación que tengo echa en EVB pasarla de "verdad" a
.NET y no este apaño que me esta tocando hacer, pero me han cambiado la
planificación y aquí me tienes haciendo apaños...

En fin, si no me recomiendas la opción de las variables globales y la
opción de conversión desde VB a .NET no la puedo usar para aplicaciones
Smart Device... se te ocurre que podría hacer?

Gracias de nuevo por tu ayuda.

Un saludo,
José Luis.

"Tristan" escribió en el mensaje
news:uV$

> Al final he optado por crear los
> formularios como variables públicas desde un modulo, me ha parecido la
> solución más sencilla

No te lo recomiendo. Creeme. Me parece la peor opción.

La forma de trabajo más similar a VB es la del punto: "¿Cómo trata este
problema el Asistente para actualización?", que es simplemente aplicar el
patrón Singleton. Con solo copiar-pegar las pocas lineas de DefInstance a
las clases de tus formularios, podrás trabajar de la misma en que lo

hacías

hasta ahora con vb. Es decir:

Mostrar un form:
Form1.DefInstance.Show()

Modificar uno de sus controles desde cualquier parte de tu aplicación:
Form1.DefInstance.TextBox1.Text = "Texto modificado"

Cerrar un form:
Form1.DefInstance.Close()

Es decir, la única diferencia con VB es que al nombre de la clase Form1,
tendrás que añadir .DefInstance.

Si sigues ese patrón, igual que en VB, cuando muestres un formulario por
segunda vez, no se creará una instancia nueva.

Realmente hacer eso mismo con variables globales no aporta ninguna

ventaja,

y si varios inconvenientes, tanto en rendimiento, como de facilidad de
desarrollo y mantenibilidad.

Juan Carlos Badiola
MVP - C#

Pues parece que la clase Control del compact framework no tiene IsDisposed.
Curioso por que parece tener la variable interna, pero no la propiedad.

Pero puedes encontrar muchas soluciones para aplicar Singleton a tus clases
Form. Este código hace lo mismo:

Private Shared mDefInstance As TuForm
Public Shared Property DefInstance() As TuForm
Get
If mDefInstance Is Nothing Then
mDefInstance = New TuForm
End If
Return mDefInstance
End Get
Set(ByVal Value As TuForm)
mDefInstance = Value
End Set
End Property

Protected Overrides Sub OnClosed(e As System.EventArgs)
MyBase.OnClosed(e)
mDefInstance = Nothing
End Sub

He quitado unas cuantas cosas del código original, que solo son útiles en un
entorno multisubproceso. Puesto que estás migrando de embedded VB, ese caso
lo descarto.


Por cierto, que conste que yo no sigo este esquema. Lo que hago es pasar a
cada objeto la información que necesita, y siempre la mínima posible, por el
tema de reducir las interdependencias entre objetos. Yo simplemente voy
pasando las referencias que van siendo necesarias, de unos objetos a otros.

Pero bueno, no te lío más, que imagino que lo que quieres es que tu
aplicación funcione cuanto antes.

Juan Carlos Badiola
MVP - C#