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…
|
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.
Guillermo
Nerja, 6/Oct/98, 03:10
P.S.
UF! Hace ya bastante tiempo, ¿verdad?
