Cada vez que miro las fechas en
que están escritas las entregas y en la que las publico, me da no
se qué... pero es que no puedo hacer más...
Aunque ahora, gracias a
Encarnica, esto puede que cunda más...
¿Quién es Encarnica... Encarni?, (que sino se puede
mosquear...)
Es la "secretaria" de la empresa... bueno, lo de
secretaria es por llamarla de alguna forma, ya que también se
encarga de otros menesteres administrativos... y ahora, además,
en sus ratos libres, se atreve a pasarme a máquina mis
"manuscritos"... trabajo que le dará por un lado,
entender mi letra y por otro entender el Visual Basic, lo mismo
hasta aprende... je, je.
¡Gracias Encarni!...
No os doy un e-mail para que les deis también las gracias, porque
no tiene, pero si
quieres agradecérselo, usa este link.
Nota: No es necesario que escribas nada, con el asunto es
suficiente, pero si escribes... que sepas que no debes incluir
consultas ni nada de eso que acostumbráis a hacer cada vez que os
encontráis con un link para enviar un mensaje... este link es
exclusivo para agradecer a Encarni el que me alivie el trabajo de
teclear y que las entregas aparezcan con mayor frecuencia...
Formularios, módulos y algo
más...
Ya
habrás visto que cada vez que se crea un nuevo proyecto, por
regla general, se añade un formulario (Form1.frm) en este
formulario podemos añadir algunos controles para “interactuar”
con el usuario… es decir, que el usuario puede escribir en las
cajas de texto, pulsar botones, etc. También, hemos visto, aunque
sea por encima, cómo controlar y poder “interceptar” algunos
eventos…
Pues, ya está… si sabes todo eso, ¿para que seguir?.
En
nuestros proyectos, podemos tener más de un formulario, por
ejemplo, uno podría ser el principal, el que hace la mayor parte
del trabajo, otro podría mostrarnos mensajes de aviso o el
resultado de cualquier ora acción…
La cuestión es que podemos usar y mostrar cuando sea conveniente
otros formularios.
Vamos
a ver un ejemplo, sencillito para no complicarnos demasiado la
vida, en el que veremos tres formularios… este ejemplo jugará a
adivinar un número y nos informará de las veces que hemos
jugado, etc. También se podrá cambiar de jugador…
El
formulario principal lo usaremos como punto de inicio, y nos
mostrará el nombre del jugador actual, las veces que ha jugado y
los puntos conseguidos, además tendrá 3 botones, uno para
cambiar de jugador, otro para jugar una partidita, y un tercero
para terminar el programa.
Usaremos otro formulario que permitirá escribir el nombre del
jugador, y otro más, que usaremos para jugar, aunque todo esto no
sería necesario, pero así es más fácil y manipulamos más
formularios.
Necesitamos
una serie de variables que sean “globales” a todo el proyecto,
por ejemplo, el nombre del jugador.
Esto podemos hacerlo de dos formas:
Añadiendo un módulo bas, y declarando una variable pública,
para que sea visible en todo el proyecto.
Otra forma sería añadiendo una variable pública al formulario
principal… También sería visible en todo el proyecto, aunque
para acceder a ella tendríamos que indicar el nombre del
formulario…
Vamos
a usar el segundo método, ya que al ser el formulario que se
usará como punta de entrada, siempre estará disponible.
Veamos el código del formulario principal al que llamaremos
frmPrincipal, para hacer esto, haz que se muestre el formulario,
pulsa F4 y en las propiedades, selecciona “name” (nombre) y
sustituye “form1” por “frmPrincipal”.
A partir de ahora, cada vez que quieras referirte al formulario
principal, tendrás que hacerlo con ese nombre: “frmPrincipal”.
Muestra
la ventana de código de este formulario y añade esto
(¿recuerdas para que sirve Option Explicit?)
Option Explicit
Public Nombre As String
Ahora
nuestro formulario tiene una nueva propiedad, a la que podremos
acceder desde el resto del proyecto usándolo de esta forma: frmPrincipal.Nombre
Este
formulario principal hace pocas cosas, no sé por qué todos los
que tienen un papel “principal” suelen hacer pocas cosas…
Bueno, al lio... La verdad es que lo único que hace es llamar a
otros formularios y acabar… tú dirás lo que quieras, pero esto
de mandar, hacer poco y además ser el “principal”… en fin…
cosas de la vida…
Vamos
a añadir un nuevo formulario, que se llamará frmNombre.
Para hacerlo, selecciona el menú Proyecto, Añadir formulario,
selecciona uno normal y ya está disponible para que le cambies el
nombre y codifiques en él.
Recuerda: pulsa F4 y selecciona la propiedad Name, borra Form2 y
escribe frmNombre.
Como
te comenté, este formulario “jefe” tiene tres botones, a los
que llamaré:
cmdNombre, cmdJugar, cmdTerminar; cada uno de ellos hace lo que
los nombres, “más o menos”, indican.
Veamos el código:
Private Sub cmdNombre_Click()
' Mostranos el form que pide el nombre
' Esto hará que se muestre y no se pueda hacer otra cosa
' hasta que se cierre u oculte
frmNombre.Show vbModal
End Sub
Ya
ves que hace poco, simplemente muestra otro formulario que se
encargará de pedir el nombre del jugador.
Aquí hay unas “cosillas” a tener en cuenta, incluso deberías
tomar nota, así que… toma nota y quédate con la copla…
Con
Show mostramos el formulario en cuestión, fíjate que se usa
NombreFormulario.Show, lo cual llama a un método propio de ese
formulario, que lo que hace es mostrarlo…
Otra cosa a tener en cuanta es que si es formulario no está
cargado en memoria, al usar este método se carga de forma
automática, esto lo veremos en más ocasiones, así que...
tranquilízate, toma aire, que todo llega…
El
método Show acepta algunos parámetros, que yo conozca son dos,
ambos son opcionales y por el momento sólo veremos el primero de
ellos.
Éste primer parámetro del método Show, lo que hace es mostrar
el formulario de forma modal o no.
Mostrar un formulario modal lo que hace es mostrar ese formulario
y no hacer otra casa en la aplicación hasta que deje de
mostrarse; es como si toda la aplicación, (la nuestra), se
congele y sólo preste atención a lo que ocurre en ese
formulario, esto es importante sobre todo cuando es necesario “esperar”
a que el usuario introduzca los datos necesarios…
Debo reconocer que cuando empecé con el Visual Basic,
esto de no saber que existía esta forma de mostrar
los formularios, me dio algún que otro come-coco…
Por suerte, aprendí que la tecla F1 servía para algo
más que estar al lado de F2...
|
Cuando
no necesites esperar a que el usuario introduzca datos o no sea
importante que se siga usando las aplicaciones a pesar de que se
muestre ese formulario; puedes mostrarlo de forma no modal, ese es
el valor por defecto del primer parámetro, es decir que si se
usa: NombreFormulario.Show, el formulario no se muestra modal,
así que “ojito”…
A
lo que vamos, usando frmNombre.Show vbModal, se muestra el
formulario y se espera a que se cierre u oculte.
Veamos
lo que hace este formulario, la verdad es que tampoco hace mucho,
salvo darle información al formulario principal. Ahora veremos
como.
El
formulario frmNombre tiene este aspecto:
Un
textbox para el nombre del usuario, un botón aceptar y otro
cancelar…
Los nombres de estos controles son: txtNombre, cmdAceptar y
cmdCancelar.
Podríamos haber usado la función InputBox para hacer
esto, pero no es lo mismo…
El botón cancelar simplemente “descarga” el formulario de la
memoria con: Unload Me.
El botón aceptar también descarga el formulario, pero antes de
eso, asigna el nombre introducido en la “propiedad” Nombre del
formulario principal, fíjate en el código para ver como se hace:
frmPrincipal.Nombre = txtNombre
Como
ya comenté antes, las propiedades de un formulario se pueden
acceder “siempre” usando el nombre del formulario en
cuestión, si no se usara… ¿cómo sabríamos qué formulario
es? La única excepción es cuando esas propiedades se usan dentro
del mismo formulario… ahora lo veremos.
Pero
esto no está bien… o casi… si dejásemos en el textbox del
formulario que se usa para pedir el nombre, el valor que hay por
defecto, es decir el que se muestra cuando se añade el control al
formulario, en este caso “Text1”, nos daríamos cuenta que
sería “más lógico” que se mostrase el nombre del usuario
actual, si hubiese alguno, por tanto se debería mostrar el nombre
y así permitir usar ese nombre o escribir uno nuevo. Esto lo
podemos hacer de dos formas:
Una: cómo la propiedad Nombre del form principal es pública,
podemos asignarla al textbox cuando se cargue el formulario que
“pide” el nombre, es decir en el evento Load de frmNombre:
Private Sub Form_Load()
txtNombre = frmPrincipal.Nombre
End Sub
La
otra forma, sería usar la posibilidad de poder “referirnos” a
los controles de un formulario desde otro formulario; se hará de
la misma forma que para acceder a una propiedad… Veamos el
código, en este caso, la asignación se hace en el procedimiento
que se encarga de mostrar el formulario frmNombre, es decir en el
evento cmdNombre_Click
Private Sub cmdNombre_Click()
frmNombre.txtNombre = Nombre
frmNombre.Show vbModal
End Sub
Nota:
Cuando se muestra un form modal, es importante no usar el
método Show dentro del código del evento Form_Load del
formulario mostrado, en el caso de que se haga, el VB nos dará
un error indicándonos que no se puede mostrar un formulario que
se está mostrando en forma modal.
Espero
que lo tengas claro, ya que te voy a complicar un poco más la
vida, aunque antes veamos unas consideraciones:
Habrás
oído de “reutilización de código” y esas otras cosillas
relacionadas con la Programación Orientada a Objetos, (OOP),
aunque no toda las buenas formas de hacer las cosas tienen que
estar relacionadas con la OOP… aunque mejor no entrar en “polémica”.
Si usamos el formulario tal como lo “he” codificado, no
podrás usarlo de forma genérica, (reutilizarlo), ya que “dentro”
de ese código se hace referencia a otro formulario… es decir,
siempre que usemos frmNombre, necesitaremos tener otro formulario
llamado frmPrincipal que al menos tenga una propiedad llamada
Nombre… Aunque no tiene porqué ser una propiedad… como hemos
visto, también podría ser un control… pero olvídate de esto
para que no te líes demasiado…
Bien,
¿cómo lo solucionamos?
Si
has leído algo sobre la programación orientada a objetos, puede
que te hayas encontrado con “palabras” como encapsulación
de…
¿Qué significa esto? Sin entrar en demasiados detalles “didácticos”,
encapsular sería tener la “autonomía” suficiente para no
depender del exterior y aún así, poder funcionar… o lo que es
lo mismo, al formulario frmNombre no le importa si el formulario
que quiere usarlo tiene o no una propiedad llamada Nombre, tampoco
le “molestará” que ese formulario se llame frmPrincipal o de
otra forma.
El que tiene que saber cosas de frmNombre, será el formulario que
quiere usarlo…
¿Qué tiene que saber?
En este ejemplo sólo existe una “propiedad” llamada txtNombre
que se encargará de “devolver” el nombre introducido… y
también debería indicar que se ha cancelado… aunque esto te lo
dejo, (por ahora), a ti… ya veremos la respuesta más adelante.
Veamos
el código tal como estaría después de todo esto que te he
explicado.
Empecemos por el final, veamos el código del formulario “encapsulador”,
(frmNombre):
Option Explicit
Private Sub cmdAceptar_Click()
Hide
End Sub
Private Sub cmdCancelar_Click()
Hide
End Sub
Ahora
te explico de que va esto… Veamos antes el código del form
principal (frmPrincipal):
Option Explicit
Public Nombre As String
Private Sub cmdNombrer_Click()
frmNombre.txtNombre = Nombre
frmNombre.Show vbModal
Nombre = frmNombre.txtNombre
Unload frmNombre
End Sub
Dirás
que nos hemos complicado demasiado… antes era más corto… no
todo van a ser ventajas, aunque si por añadir dos líneas de
códigos ganamos un formulario que es independiente… tu decides…
Aunque, personalmente, este último código lo escribiría así:
Private Sub cmdNombrer_Click()
With frmNombre
.txtNombre = Nombre
.Show vbModal
Nombre = .txtNombre
End With
Unload frmNombre
End Sub
Ahora
tenemos más líneas de código, pero ganamos en claridad…
además si te acostumbras a usar With, (según dicen), el código
es más rápido, al menos cuando se hacen referencias a objetos
con distintos “niveles”, este no es el caso, pero ya te
toparás con casos de múltiples referencias… todo llegará…
Antes
de seguir “encontrando” pegas, veamos porqué ha cambiado
Unload Me por Hide:
| Unload |
Descarga
un formulario de la memoria, después de Unload se debe
indicar el nombre del formulario. En este caso se usa Me
para indicar que se descarga el formulario en el que
esté esa instrucción. |
| Hide |
Simplemente
oculta el formulario, pero no lo descarga. |
La
diferencia está en que si “descargamos” el formulario, lo “borramos”
de la memoria, por tanto “destruimos” todo el contenido y lo
que hubiese “almacenado” en los controles y esto no es lo que
nos interesa, ya que necesitamos “conservar” el contenido del
txtNombre para que el código que use frmNombre pueda saber el
nombre que se introdujo.
Un lío ¿verdad? Pues si te lías con cuatro líneas de código,
no sabes lo que te espera... je, je.
Espero
que te vayas quedando con la “esencia” y que vayas asimilando
cosas… no pretendas saber programar… lo que pretendo es que al
final, (si es que esto puede terminar algún día), sepas
programar y por extensión saber desenvolverte con el Visual
Basic.
Ahora
te dejo con el ejercicio de mejorar lo presente, por ejemplo que
el formulario principal sepa que se ha pulsado en Cancelar… no
te comas mucho el “coco” y no te compliques demasiado, intenta
buscar soluciones “fáciles”, que las hay…
aunque
también puedes “complicarte la existencia” y hacerlo de otra
forma diferente… usando otras propiedades, por ejemplo… ops!
...creo que me he pasado con la “ayuda”…
En
la próxima entrega seguiremos… que ya es tarde y mañana hay
que currar…
Pincha este link para ver una de las soluciones…
Nos
vemos.
