Private Sub Command1_Click()
    '
    Dim SumaActual As Long
    Dim i As Long

    SumaActual = 0
    For i = 1 To 5000
    SumaActual = SumActual + 1
    Next

    MsgBox "El contenido de SumaActual es " & SumaActual
End Sub

Pulsa F5, haz click en el Command1 y verás que no hace lo que se espera...
Ya que si analizas el código, el valor mostrado debería ser 5000, pero, no es así...
Vamos a dejar que el VB descubra el error por nosotros; para ello vamos a ejecutar de nuevo el programa, pero esta vez añade Option Explicit al principio del módulo, es decir en la parte de las declaraciones generales del formulario, vuelve a ejecutar de nuevo el programa, nada ocurre... pulsa en el botón Command1 y verás que si que había un error tipográfico.

Seguramente dirás que tampoco es para tanto... total, si se escriben bien los nombres de las variables... pues sí, pero cuando tengas proyectos con varios formularios y algunos módulos de otro tipo... entonces ya me contarás si no es mejor contar con "detector de errores tipográficos".

Seguramente te habrás fijado que al ejecutar el programa, (usando F5 o pulsando en el botón de la barra de herramientas), el Visual Basic no te ha avisado del fallo, sólo lo ha hecho cuando has hecho click en el botón, esto está bien, pero no ayuda mucho cuando el proyecto es grande y tiene varios formularios y varios/muchos procedimientos, ya que hasta que no se ejecute el código que hay en ellos no nos avisará del "fallo".

Pero, por suerte, esto se puede evitar... y además de dos formas distintas.
La primera es ejecutando la aplicación con Ctrl+F5, es decir pulsando la tecla control y al mismo tiempo F5, de esta forma se analiza todo el código antes de iniciar el programa y si el Visual Basic encuentra algún error, te avisará.
La otra forma es indicarle al VB que "siempre" analice el código antes de ejecutarlo, de esta forma es como si siempre pulsáramos Ctrl+F5 aunque sólo se pulse F5. Para que esto sea así, muestra el cuadro de diálogo de Herramientas y en la solapa General busca la casilla "Compile on demand" (o como sea en la versión en español), si está marcada esta opción, quítale la marca, esto en proyectos grandes hace que tarde un poquito más al ejecutarse en el IDE, pero es porque se analiza todo el código antes de empezar la ejecución del programa, yo ya me he acostumbrado a que siempre se compile y lo tengo de esta form, ya que no hay nada que más me moleste que se detenga el programa al entrar en un procedimiento por culpa de un error tipográfico, la verdad es que si esta opción hubiese estado en el Basic del MS-DOS nos hubiera evitado algún que otro quebradero de cabeza, por desgracia llegó tarde, con el Visual Basic para DOS, pero más vale tarde que nunca... aunque ahora casi ni se utiliza...

Para terminar con esto de las ventajas de usar Option Explicit, vamos a ver cómo saber si una variable está en uso o no.
Bueno, no es que nos de esa información, pero algo parecido, la verdad es que echo de menos una característica del QuickBasic del MS-DOS y era que al pulsar F1 en una variable, nos indicaba en que módulos se estaba usando dicha variable, pero... aunque no existe esa forma de ver cómo está declarada una variable en el Visual Basic, podemos usar otra forma, que es pulsando Shift+F2; te mostrará la declaración de esa variable... si no te muestra la declaración, es que no está declarada.

A lo que iba, si tenemos declarada una variable, se respeta el "estado" de mayúsculas/minúsculas de ese nombre de variable, por tanto si en el caso del ejemplo anterior, hubiésemos escrito (todo en minúsculas) sumaactual, el VB automáticamente hubiese convertido dicho nombre a SumaActual o como lo hubiésemos escrito al DIMensionarla; esta es una de las formas de saber si ya tenemos la variable declarada... aunque sea en otro procedimiento... el único "fallo" es que el VB recuerda la última forma en que se dimensionó una variable... es decir, si en un procedimiento tenemos esta declaración:
Dim j As Integer y en otra parte de nuestro proyecto esta otra:
Dim J As Integer, el VB convertirá todas las variables "j" al estado de la última declaración que hayamos usado...
Pero al menos sabremos que la tenemos declarada y de esto vamos a ver más cosas...

Declarar las variables del tipo adecuado

Ya que estamos en esto de las declaraciones de las variables, voy a darte otro consejo, que si no estan evidente como el anterior, en algunas ocasiones puede hacer que tu aplicación trabaje de forma más eficiente... aunque no te voy a hacer ninguna demostración, ya que la demostración la tuviste en la entrega cuatro.
La recomendación es que declares las variables con el tipo adecuado, es decir, que especifiques el tipo de la variable cada vez que la declares, si no lo haces, el Visual Basic le asignará el tipo por defecto, que normalmente suele ser Variant y aunque ese tipo sirva para todo, no es el recomendable para muchas ocasiones, al menos en lo que a bucles se refiere, por poner un ejemplo.
También puedes especificar el tipo por defecto, esto yo lo hacía siempre en mis programas de MS-DOS, aunque ahora en Visual Basic para Windows no lo suelo hacer, ya que siempre declaro las variable del tipo que quiero que tengan.
Pero para que lo puedas hacer, aunque me imagino que ya sabrás, te recuerdo cómo hacerlo.

Añade justo después del Option Explicit la instrucción DEFxxx a-z, sustituye las xxx por el tipp de tu preferencia, por ejemplo:
DefInt A-Z asignará el tipo Integer a todas las variables declaradas sin un tipo determinado; por otro lado:
DefLng A-Z hará que el tipo predeterminado sea el Long.

Se pueden usar varios de estos DEFxxx usando distintos rangos de letras, ya que el Defxxx funciona de esta forma:
Deftipo rango letras [, rango2 [, rango3, etc]]
dóde tipo es Int para Integer, Lng para Long, Sng para Single, etc. (busca esta palabra en la ayuda para más información)
Los rangos son letras que le indicarán al VB que las variables que empiecen por esas letras sean del tipo indicado, por ejemplo:

DefInt a-c, i, j
DefLng L-N, R

Declarará las variables, siempre que no se especifique el tipo, que empiecen por a, b, c, i y j como variables Integer y las que empiecen por L, m, n y r como Long.
Por ejemplo con estas declaraciones:
Dim Ahora, Nombre As String, Longitud, Resultado As Currency

Ahora será Integer, Longitud será Long y las otras dos, del tipo indicado: Nombre es String y Resultado del tipo Currency.
Pero ya te digo que prefiero declarar las variables del tipo adecuado, es decir especificando el tipo que será:
Dim Ahora As Integer, Nombre As String, Longitud As Long, Resultado As Currency
Yo así lo tengo más claro, pero puedes hacerlo como prefieras.

Lo que si debes hacer es usar el tipo que realmente necesites, por ejemplo si vas a hacer bucles que no supere el valor 32767, puedes usar una variable de tipo Integer, si quieres guardar en sDatos una cadena, declarala como tipo String, etc.
Ya que si siempre als declaras como el valor por defecto y se te olvida añadir el DEFxxx correspondiente, tendrás que las variables será del tipo Variant, que entre otras cosas es más lenta y ocupa más memoria. Además de que en un futuro te será más fácil saber el tipo de datos que esas variables contendrán... cosa que agradecerás cuando veas de nuevo el código unos meses o años después...
Y para que te sea más fácil recordar que debe almacenar cada variable:

Usa nombres descriptivos para las variables

Pues eso, es más fácil saber que la variable "Nombre" guarda un nombre que si sólo usas "n"
Aunque en esto de dar nombre de las variables, coincido con otros programadores, de usar ciertas variables "no descriptivas" para ciertas cosas, no es por nada, sino porque como todos, he aprendido viendo código de otros programadores y siempre se te pega algo del "estilo" que se va generalizando... por ejemplo, en el uso de las variables i, j, k para los bucles.

Otro aspecto es el de usar ciertos "prefijos" para indicar el tipo y la visibilidad de las variables... en esto no todos estamos de acuerdo, pero casi... Seguramente habrás "oido" hablar de la notación "hungara"... no voy a entrar en detalles de que va esto, pero si decirte más o menos como se aplica, al menos en algunos casos, a la hora de declarar las variables.
Para simplificar, y mucho, te diré que el prefijo es la letra o letras (normalmente tres), que se usan delante del nombre de la variable, por ejemplo, las variables del tipo Integer se declararían así:
Dim intContador As Integer, lngContador As Long, strNombre As String, etc...
De esta forma, es fácil saber que strNombre es del tipo String, aunque no tengamos "cerca" la declaración de la variable.
Yo suelo abreviar el tema y suelo declararlas de esta otra forma: (como otros programadores, que no vayas a creer que es invención mia)
Dim iContador As Integer, sNombre As String
Con el tipo Long no siempre uso la "l" (ele minúscula), entre otras cosas porque se confunde con el número "1" y casi siempre suelo declarar las variables Long con "lng".
Para los otros tipos no suelo hacerlo de ninguna forma en particular, aunque el tipo "boolean" las declaro con la letra "b".
En el caso de que las variables sean públicas no suelo añadirle ningún tipo de identificador, ya que en el caso de los formularios se convierten en propiedades, no entro en más detalles en esto de las propiedades, ya que será el tema de la próxima entrega.

Pero esto de los prefijos no sólo se aplican a las variables, también se hace a los controles y formularios.
Por ejemplo:

Para los tipos definidos las declaraciones del tipo suelo empezarlos con "t_" y las variables declaradas a partir de un tipo con "t", las enumeraciones (ya las veremos en su momento), las empiezo por "e" y las constantes con "c"...
En el caso de las variables a nivel de módulo, las que son visibles en todo el módulo actual, ahora veremos más sobre esto, suelo anteponerle el prefijo "m_". Aunque todo hay que decirlo, no tengo un estilo fijo en esto de nombrar a las variables y controles, aunque en la mayoría de los casos, es éste el que suelo aplicar... y cada vez con más "consistencia", ya que a la larga te ayuda el usar algún tipo de recordatorio del tipo/nivel de visibilidad de los controles y variables.

Para ir acabando con las recomendaciones del día, voy a darte la penúltima:

Usa comentarios en tus listados

Y es que los comentarios, entre otras cosas, no ocupan espacio en el programa una vez compilado y a la larga, siempre es a la larga, ya que cuando el código está reciente, nos acordamos de todo... pero cuando se lee después de pasado algunos meses... puede que te ocurra lo que a mi... que al estar revisando listados antiguos, tuve que entender lo que hacia el código y después comentarlo para que la próxima vez que tuviese que modificarlo, me resultara más fácil.
Por tanto, si no quieres verte en este aprieto, usa y abusa de los comentarios, aunque sea un poco "pesado", te repito que se agradece, sobre todo si el código cae en manos de otro programador, por ejemplo en un grupo de trabajo y tiene que entender lo que "pretendías" hacer...

La visibilidad o "cobertura" (o si lo prefieres: ámbito) de las variables.

¿De que va esto de la visibilidad?

Esto va de que cuando se declaran las variables, estas no están visibles en toda la aplicación...
¡AH! que lo que no entiendes es lo de "visible"...
Te lo explico con un ejemplo:
Supón que tienes un procedimiento que cuenta el número de veces que una letra está en una cadena, por ejemplo en "Visual Basic" la letra "a" está dos veces, talvez no tenga mucha utilidad este ejemplo, pero...

En este código hay dos variables declaradas: "i" y "nVeces", pues bien, estas variables sólo son visibles dentro de esta función, es decir, que no tendrán nada que ver con otras variables que tengan el mismo nombre, y estén declaradas en otros sitios.

Talvez este ejemplo "solitario" no esté demasiado claro. Pero es un fallo que muchos "cometemos", (o al menos, algunos hemos cometido, aunque ya lo tengamos superado... o casi.)
He visto más de un listado en el que se declara una variable en un procedimiento y después se "intenta" usar en otro sitio distinto en el cual "no se ve" esa variable... Por supuesto, estos problemas de "visibilidad" se evitan usando Option Explicit... realmente no se evitan... sino que nos "obliga" (el VB) a que lo evitemos... ya que no nos dejará usar el programa si no están las variables "debidamente" declaradas... o al menos declaradas aunque no sea de la forma adecuada... (ver más arriba lo que comento sobre usar el tipo adecuado).

Vamos a verlo con un ejemplillo... para que te des cuenta de lo que podías haberte evitado si usaras el Option Explicit... y si aún no te ha dado tiempo a comprobarlo, porque eres de los que siguen "las reglas", ahora te darás cuenta de que podía haber sido peor tu aprendizaje...

Para este ejemplo, tendrás que crear un nuevo proyecto, se añade por defecto un formulario (Form1), añade un módulo BAS (Module1) y escribe lo siguiente en el módulo BAS:

Escribe esto en el formulario (Form1) que tendrá un TextBox (Text1) y botón (Command1):

Ejecuta el programa y verás que cuando pulses en el Command1, no te muestra el nombre y las veces siempre serán cero... aunque pulses varias veces.

¿Por qué ocurre esto si las variables sNombre y nVeces están declaradas como públicas en el módulo BAS?
Esto es así, porque a pesar de haber declarado esas dos variables como públicas en el módulo BAS, (es decir visible en todo el proyecto), no se ha asignado nada a ellas...
¿Seguro?
Entonces, ¿que pintan las asignaciones: sNombre = Text1 y nVeces = nVeces + 1 que hay en el procedimiento Command1_Click?
Te lo explico:
El caso de sNombre es más fácil de comprender, a saber, cuando el Visual Basic entra en el procedimiento Command1_Click, declara una variable de tipo cadena llamada sNombre, esa variable sólo es visible dentro de este procedimiento, es decir que cuando se use, el VB usará la memoria que ha reservado al encontrarse esa declaración, por tanto el contenido del TextBox se guardará en ese espacio de memoria, osea: la variable sNombre del procedimiento Command1_Click.
En el caso de nVeces es parecido al de sNombre, pero en este caso la "visibilidad" de esta variable es más amplia que la de sNombre, ya que al estar declarada a nivel de módulo, es visible en todo el formulario, pero al ser privada sólo será visible, (o accesible, o disponible, como prefieras), dentro del código que esté en el propio formulario y no fuera de él.
Por tanto, al llamar al procedimiento MostrarNombre, (que está declarado como público en el módulo BAS y por tanto disponible en todo el proyecto), el VB se encuentra con que queremos usar dos variables... comprueba si está debidamente declaradas y usa los valores que contienen... es decir, ninguno; por tanto muestra los valores por defecto... una cadena vacia y un valor cero.

Esto en inglés se llama "scope", ámbito o alcance; si lo entiendes mejor es la "cobertura" que tiene esa variable, como la de los teléfonos móviles (celulares) o emisoras de radio... si no tiene cobertura en una zona, no se escuchará en esa zona...

Vamos a ver las distintas formas de declaración de una variable, para ver el "alcance" que tienen:

-Declaradas en un procedimiento (Sub, Function o Property)

Sólo son visibles en ese procedimiento

-Declaradas Privadas (o con Dim) en un formulario o módulo (BAS, CLS u otro tipo)

Sólo son visibles en ese formulario o módulo, incluidos todos los procedimientos de ese módulo, salvo la restricción anterior.

-Declaradas Públicas (o Globales) en un módulo BAS

Son visibles en todo el proyecto, salvo cuando se encuentren con variables declaradas en los casos anteriores.

-Declaradas Públicas en formularios o módulos de clase

Serán visibles en cualquier sitio, siempre que se preceda con el nombre del formulario o clase... (ya veremos esto en otra ocasión)
O sólo dentro de ese módulo, como si fuesen privadas al propio módulo.

Por tanto, las variables que tengan el mismo nombre, se usarán según la última declaración que tenga esa variable y si está al alcance del procedimiento en el que se está usando... que lio, ¿verdad?

Esta cercanía en la declaración de la variable se puede explicar también así:

• Primero se usarán las que estén declaradas en el propio procedimiento
• Después las que estén en el mismo módulo (o formulario o clase o... cuando digo módulo, me refiero al "sitio" en el que escribes el código)
• Por último, las declaradas como globales o públicas en un módulo BAS

Hay que puntualizar que las variables públicas declaradas en un formulario, módulo de clase o control de usuario, se convierten en propiedades de esos "objetos", y como sabrás para usar una propiedad de un "objeto", debes especificar el nombre del objeto seguido de un punto y después el nombre de la propiedad; aunque cuando se usan en el mismo módulo o formulario, no es necesario usar el nombre del "objeto que las contiene", por tanto, si no se especifica el nombre del módulo, sólo son visibles dentro del mismo módulo en el que se han declarado.

Para que el ejemplo anterior funcionara como debe, tendrás que quitar las declaraciones que hay de las variables sNombre y nVeces en el formulario y sólo dejar las del módulo BAS.
Pruébalo y verás que ahora si que se muestra lo que se debe mostrar.

Usar una variable indicando el módulo en el que se han declarado

Ya que he tocado el tema de especificar el nombre del "objeto" delante de las variables, también se pueden usar de esa forma y así evitaríamos el tema este de la visibilidad y alcance de las variables, aunque es algo más "liante"...
Esta forma de usarlo fuera del módulo en el que se ha declarado, sólo es válido si las variables son "públicas".
Para verlo, un ejemplo:
Crea un nuevo proyecto, se creará un formulario (Form1), añade un módulo BAS (se creará Module1, no le cambies el nombre al módulo)
Escribe esto en el módulo BAS y el formulario, según se especifica:

Creo que los comentarios son aclaradores, así que ejecútalo y verás lo que muestra, prueba a quitar Module1 cuando se use y asigne a "unaVariable" y verás que el primer valor se pierde (como debe ser...).

Bueno, aunque he tardado en publicarla... al fin hemos continuado con las entregas del cursillo básico...
La verdad es que el manuscrito era del 30 de Septiembre, empecé a escribirlo en el OutLook Express cuando estaba en Canarias el 29 de Octubre y por fin lo he acabado el 6 de Diciembre... pero más vale tarde que nunca... ¿verdad?
Confío en que haya servido de algo tanta espera... así que si quieres hacer algún comentario... hazlo pulsando en este link...

Nos vemos.