Curso Básico de Programación
en Visual Basic

Entrega Veintiocho: 28/Mar/99
por Guillermo "guille" Som

Si quieres linkar con las otras entregas, desde el índice lo puedes hacer

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 agradecerselo, 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 acostumbrais a hacer cada vez que os encontrais 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 Explict
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 escribre 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 mostralo… 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 oido 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 asi, 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 los 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:

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?

Ir a la entrega anterior (la 27)