Introducción:
Debido a que la nueva versión de Visual Basic
no es sólo una mejora con respecto a las versiones anteriores, sino que cambia
mucho, tanto como si de otro lenguaje de programación se tratara, creo que se
merece que se explique de forma más o menos fácil de comprender para que
cualquiera que se decida a elegirlo como su lenguaje de programación lo tenga,
valga la redundancia, fácil.
Tan fácil como permitan las circunstancias, y además, (para
que esto de estudiar no resulte algo tedioso), tan ameno
como me sea posible, ya que las cosas se pueden explicar de muchas formas y, a
pesar de parecer que peco de falta de modestia, estoy seguro que este curso de
iniciación a la programación con Visual Basic .NET te va a resultar
ameno y fácil de comprender... ¡seguro!
Pero no sólo vas a aprender a programar con VB.NET, sino que al estar
"basado" en el .NET Framework, conocerás lo suficiente de este
marco de desarrollo que podrás atreverte con otros lenguajes .NET, tales como
c#, ya que al fin y al cabo, el corazón de los lenguajes .NET es el .NET
Framework.
Para ir aclarando ideas, veamos algunos
conceptos que habrá que tener claros desde el principio:
Visual Basic .NET usa una jerarquía de clases que están incluidas en el .NET
Framework, por tanto conocer el .NET Framework nos ayudará a conocer al propio
Visual Basic .NET, aunque también necesitarás conocer la forma de usar y de
hacer del VB ya que, aunque en el fondo sea lo mismo, el aspecto sintáctico es
diferente para cada uno de los lenguajes basados en .NET Framework, si no fuese
así, ¡sólo existiría un solo lenguaje!
Me imagino que la primera pregunta a la que
habría que responder es:
¿Qué es el .NET Framework?
Voy a intentar dar una respuesta que sea fácil
de "asimilar", a ver si lo consigo...
Primer intento, lo que se dice en el eBook
Microsoft .NET Framework,
cuya
versión en Castellano puedes conseguir usando este link: (este link está
actualizado, al menos a fecha de hoy 10 de noviembre de 2002)
".NET Framework es un entorno para
construir, instalar y ejecutar servicios Web y otras aplicaciones.
Se compone de tres partes principales: el Common Language Runtime, las clases
Framework y ASP.NET"
Aunque dicho libro está basado en la Beta1 es
válido para aclarar conceptos sobre lo que es el .NET Framework además de
otros conceptos como el Common Language Runtime (CLR), Common Language
Specification (CLS), Common Type System (CTS), Microsoft
Intermediate Language (MSIL), los ensamblados o assemblies, así como
sobre ASP.NET, conceptos que si bien no son imprescindibles para poder
usar Visual Basic .NET, es conveniente leer un poco sobre ellos, para no estar
totalmente perdidos cuando nos encontremos con esos conceptos...
Segundo intento, lo que dice la MSDN Library:
"El .NET Framework es un entorno
multi-lenguaje para la construcción, distribución y ejecución de Servicios
Webs y aplicaciones."
"El .NET Framework es una nueva plataforma diseñada para simplificar el
desarrollo de aplicaciones en el entorno distribuido de Internet."
"El .NET Framework consta de dos componentes principales: el Common
Language Runtime y la librería de clases .NET Framework."
Tercer intento, aclarando las cosas, para que se te "queden" grabadas:
El .NET Framework es el corazón de .NET,
cualquier cosa que queramos hacer en cualquier lenguaje .NET debe pasar por el
filtro cualquiera de las partes integrantes del .NET Framework.
El Common Lenguage Runtime (CLR) es una serie de librerías dinámicas (DLLs),
también llamadas assemblies, que hacen las veces de las DLLs del API de Windows
así como las librerías runtime de Visual Basic o C++. Como sabrás, y si no lo
sabes ahora te lo cuento yo, cualquier ejecutable depende de una forma u otra de
una serie de librerías, ya sea en tiempo de ejecución como a la hora de la
compilación. Pues el CLR es eso, una serie de librerías usadas en tiempo de
ejecución para que nuestros ejecutables o cualquiera basado en .NET puedan
funcionar. Se acabó eso de que existan dos tipos de ejecutables: los que son
autosuficientes y no dependen de librerías externas o los que necesitan de
librerías en tiempo de ejecución para poder funcionar, tal es el caso de las
versiones anteriores de Visual Basic.
Por otro lado, la librería de clases de .NET Framework proporcionan una
jerarquía de clases orientadas a objeto disponibles para cualquiera de los
lenguajes basados en .NET, incluido el Visual Basic. Esto quiere decir que a
partir de ahora Visual Basic ya no será la "oveja negra" de los
lenguajes de programación, sino que tendrá a su disposición todas las clases
disponibles para el resto de los lenguajes basados en .NET, (o casi), con lo
cual sólo nos diferenciará del resto de programadores en la forma de hacer las
cosas: ¡más fáciles!
VB.NET ahora es totalmente un lenguaje orientado a objetos con herencia y todo.
También permite crear Threads o hilos o tramas de ejecución y otras cosas que
antes nos estaban vetadas. De todo esto veremos en esta serie de
"entregas", espero que, aunque es un poco más complicado que el
Visual Basic de "siempre", confío en que te sea fácil de asimilar.
¡A ver si lo consigo!
Sobre la versión de Visual Basic .NET:
A la hora de escribir estas líneas, la
versión de Visual Basic .NET que hay disponible es la que se incluye en la Beta2
de Visual Studio .NET. Pero según dicen, la versión final tendrá pocos cambios
con respecto a la Beta 2, así que, espero que todo lo que aquí explique sea
válido para la versión definitiva de Visual Basic .NET.
Algunas aclaraciones preliminares:
Antes de empezar a ver el
código, un par de aclaraciones, que aunque ahora puede ser que te suenen a
chino, (si eres chino o conoces ese idioma, sólo decirte que es una frase
hecha: "me suena a chino" es como decir: "no sé de que me estás
hablando"), pronto serán tan usuales que acabarás por asimilarlas
como si toda tu vida las hubieras estado usando... o casi...
Extensión de los ficheros
de código.
En Visual Basic .NET a diferencia de lo que ocurría en las versiones anteriores
de Visual Basic, sólo existe un tipo de fichero de código, el cual tiene la
extensión .vb, en este tipo de fichero pueden coexistir distintos tipos
de elementos, por ejemplo: un módulo de clase, un formulario, un módulo
de código, un control, etc.; mientras que en las versiones anteriores de Visual
Basic, cada uno de estos elementos tenían su propio tipo de fichero con su
respectiva extensión. Si no sabes o no quieres saber de lo que ocurría en las
versiones anteriores, me parece muy bien... pero esto sólo es para que lo sepas
y no te sorprenda, si es que hay algo que aún puede sorprenderte, claro.
Tipos de ejecutables.
Con Visual Basic .NET puedes crear básicamente estos dos tipos de ejecutables:
de consola, no gráfico, al estilo del viejo MS-DOS, y
gráficos, como los que normalmente estamos acostumbrados a ver en Windows.
Existen otros tipos de aplicaciones que se pueden crear con Visual
Basic .NET: aplicaciones ASP.NET, (realmente no es una aplicación o ejecutable,
sino un compendio de distintos tipos de elementos...), servicios Web, servicios
Windows, etc.
Nuestra primera aplicación con Visual Basic .NET.
Para ir calentando motores, creo que lo mejor
es empezar creando una pequeña aplicación con VB.NET, después iremos
aclarando los distintos conceptos usados... así te resultará menos complicado
todo lo que tengo preparado para ti.
Inicia el Visual Studio .NET,
por defecto te mostrará la "página de inicio" desde la cual pueden
crearse nuevos proyectos o bien abrir alguno de los más recientemente abiertos.
Pulsa en Nuevo proyecto
Te mostrará los diferentes
tipos de proyectos que se pueden crear, en el panel izquierdo selecciona
Proyectos de Visual Basic (Visual Basic Projects) y de los que muestra en el
panel de la derecha, selecciona Console Application
Tendrás que especificar el
directorio en el que se guardará el proyecto, así como el nombre del mismo,
(creando un directorio con el nombre del proyecto indicado), deja el nombre que
muestra por defecto, en la versión inglesa de Visual Studio .NET se llamará
ConsoleApplication1. Pulsa en OK (Aceptar) y se creará el proyecto.
Por defecto te mostrará lo
siguiente:
Es decir, creará un fichero
llamado Module1.vb, (mostrado a la derecha en el Solution Explorer), con el
código necesario para empezar a escribir. Fíjate que además del procedimiento
Sub Main, el cual se usará como punto de entrada de nuestro ejecutable,
también ha creado una "definición" llamada Module Module1 con
su respectivo End Module, el cual indica dónde termina la definición
del módulo. Esto es así, porque, como te dije hace un rato, en un mismo
fichero .vb, pueden existir distintos tipos de elementos. Por ahora, dejémoslo
así... ya habrá tiempo de complicarnos la vida...
Una aclaración: lo que estamos creando es una aplicación tipo
consola, es decir, no se creará ninguna ventana gráfica, sino que el
ejecutable que vamos a crear funciona desde una ventana de MS-DOS (o consola).
Esto lo comprobaremos cuando ejecutemos el proyecto.
Lo que queremos, (o mejor
dicho, lo que YO QUIERO), mostrar, es un mensaje que diga algo así como: Hola
mundo .NET ¡que original! ¿verdad?, por tanto para mostrar un texto en la
"consola", usaremos una función, método o instrucción, (como
prefieras llamarla), que si bien no es nativa de Visual Basic .NET, la usaremos
como si lo fuese... como veremos más tarde, TODO esto es posible gracias a los
assemblies o a las clases incluidas en el .NET Framework. Por ahora simplemente
confía en mi y escribe lo que te voy a decir.
La función en cuestión, (realmente todo lo que se usa en .NET son funciones),
es Console.Write y se usa de la siguiente forma:
Console.Write("Hola mundo .NET"), es decir incluiremos dentro
de paréntesis lo que queremos que se muestre en la consola, en este caso
queremos mostrar un texto, el cual hay que incluirlo dentro de comillas dobles.
Escríbelo entre el Sub Main() y el End Sub. Comprueba que cuando
escribas Console y el punto, se mostrarán las funciones que Console pone a
nuestra disposición, así como una pequeña ayuda, en modo de ToolTip, aunque a
esto, o a algo parecido, ya estarás acostumbrado si has usado alguna vez el
Visual Basic 5/6.
Bien, ya tenemos todo lo que
necesitamos. Ahora tendremos que indicarle al "Entorno Integrado"
(IDE) que compile el proyecto y lo ejecute, y después de compilarse el
proyecto, se deberá mostrar el texto en una ventana de DOS (o consola).
(Guille, ¿por qué me da la impresión de que no se va a mostrar nada? te
gustaría preguntarme en este preciso momento)
Para salir de dudas, pulsa F5 (o a la flecha azul o botón con figura de PLAY de
un reproductor)
Pregunta: ¿Que ha pasado?
Respuesta: Realmente se ha mostrado el mensaje en una ventana de
consola...
(salvo que hayas cometido algún error, cosa que sólo
habrá ocurrido si en lugar de estar leyendo, te has dedicado a hacer tus
propias pruebas, así que... ¡HAZ EL FAVOR DE ATENDER EN CLASE! ¡ya tendrás
tiempo de hacer tus propias pruebas!)
P: Entonces, ¿por qué no se ve?
R: Porque después de mostrarse se ha cerrado la ventana.
P: ¿Cómo podemos ver el mensaje?
R: Ejecutando el EXE desde una ventana de DOS (o consola)
Pero lo mejor sería hacer que el programa se pare hasta que pulsemos la tecla
Intro. Para ello, añade la siguiente línea a continuación de la anterior:
Console.Read()
Pulsa de nuevo F5 y verás como esta vez si que se muestra el mensaje, además
de que la ventana no se cierra hasta que pulses Intro.
Realmente puedes escribir lo que te de la gana y se irá mostrando en la ventana
de consola, pero hasta que pulses Intro no dejará de mostrarse. (Tampoco iba a ser el primer ejemplo tan perfecto... ¡que te
crees!).
Pues ésta es nuestra primera
aplicación con el Visual Basic .NET.
Realmente tan inútil como poco práctica, pero... queda muy bien eso de saber
que ya somos capaces de crear nuestros propios ejecutables. La verdad es que a estas alturas (o mejor dicho bajuras) del
curso o tutorial no pretenderás hacer cosas más "sofisticadas",
entre otras razones, porque se supone que no sabes nada de nada... ¿cómo? que
si que sabes... que ya has trabajado antes con el Visual Basic... que incluso te
has leído mi Curso Básico de VB... entonces... tendrás que esperar algunas
entregas o unirte al grupo de estudiantes noveles (o principiantes o novatos
o... como quieras llamarlos) y esperar a que los conceptos básicos estén
aclarados, ya que este curso es un curso de iniciación y si los que lo
siguen ya supieran tanto como tú, no sería un curso de iniciación... pues
eso... (¡que borde (desagradable)
eres algunas veces Guille!)
Olvidemos a los otros
Guilles y sigamos...
Antes de continuar, vamos a
conocer un poco sobre el entorno de desarrollo de Visual Studio .NET, (que es el
que se usa con Visual Basic .NET), para que podamos configurar algunos aspectos,
por ejemplo para indicar cómo se comportará el compilador e intérprete sobre
el código que escribamos o para configurar las librerías (assemblies) que se
usarán en nuestras aplicaciones. Recuerda que Visual Basic .NET usa una serie de
librerías (de clases) con las funciones que necesitemos en cada momento...
¿Te parece complicado? No te
preocupes... ahora simplemente lee y pronto entenderás, pero por favor:
¡lee! no intentes pasar todo este "rollo" por alto, ya que si no te
enteras de lo que te estoy contando, seguramente acabarás preguntándomelo
por e-mail y la única respuesta que recibirás por mi parte es que te vuelvas
a leer toda esta parrafada... gracias.
Por ejemplo, para poder mostrar
un texto en la consola, necesitamos tener disponible la librería en la cual
está declarada la clase Console, para que podamos acceder a las
funciones que dicha clase pone a nuestra disposición, (por ejemplo Write o
Read); en este caso la librería en la que está la clase Console es: System.
System realmente es un Namespace o espacio de nombres, no es una
librería o assembly.
¿Que es un Namespace (o espacio de
nombres)?
"Un espacio de
nombres es un esquema lógico de nombres para tipos en el que un nombre de
tipo simple, como MiTipo, aparece precedido por un nombre jerárquico separado
por puntos. [...]"
Así es como lo definen en el
eBook de .NET Framework que mencioné al principio.
Para que nos entendamos, un Namespace, (prefiero usar el nombre en inglés, ya
que así es como aparecerá en el código), es una forma de agrupar clases,
funciones, tipos de datos, etc. que están relacionadas entre sí. Por ejemplo,
entre los Namespaces que podemos encontrar en el .NET Framework encontramos uno
con funciones relacionadas con Visual Basic: Microsoft.VisualBasic. Si te
fijas, Microsoft y VisualBasic están separados por un punto, esto significa que
Microsoft a su vez es un Namespace que contiene otros "espacios de
nombres", tales como el mencionado VisualBasic, CSharp y Win32
con el cual podemos acceder a eventos o manipular el registro del sistema...
Para saber que es lo que
contiene un Namespace, simplemente escribe el nombre con un punto y te
mostrará una lista desplegable con los miembros que pertenecen a dicho
espacio de nombres.
Por regla general se deberían
agrupar en un Namespace funciones o clases que estén relacionadas entre sí. De
esta forma, será más fácil saber que estamos trabajando con funciones
relacionadas entre sí.
Pero el que distintos espacios de nombres pertenezcan a un mismo Namespace,
(viene bien esto de usar la traducción castellana e inglesa de una palabra,
para no ser redundante), no significa que todos estén dentro de la misma
librería o assembly. Un Namespace puede estar repartido en varios assemblies o
librerías. Por otro lado, un assembly, (o ensamblado), puede contener varios
Namespaces.
Pero de esto no debes preocuparte, ya que el IDE de Visual Studio .NET se encarga
de "saber" en que assembly está el Namespace que necesitamos.
¿Que es un assembly (o ensamblado)?
"Un ensamblado es el
bloque constructivo primario de una aplicación de .NET Framework. Se trata de
una recopilación de funcionalidad que se construye, versiona e instala como
una única unidad de implementación (como uno o más archivos). [...]"
Para que nos entendamos,
podríamos decir que un assembly es una librería dinámica (DLL) en la cual
pueden existir distintos espacios de nombres. Aunque esto es simplificar mucho,
por ahora nos vale.
Un ensamblado o assembly puede
estar formado por varios ficheros DLLs y EXEs, pero lo más importante es que
todos los ensamblados contienen un manifiesto (o manifest), gracias al cual se
evitan muchos de los quebraderos de cabeza a los que Windows nos tiene
acostumbrados, al menos en lo referente a las distintas versiones de las
librerías y ejecutables, seguramente habrás oído hablar de las DLL Hell
(o librerías del demonio) expresión que se usa cuando hay incompatibilidad de
versiones entre varias librerías que están relacionadas entre si.
Por ejemplo, supongamos que tenemos una librería DLL que en su primera versión
contenía X funciones. Al tiempo, se crea la segunda versión de dicha librería
en la que se cambian algunas funciones y se añaden otras nuevas, para mejorar
el rendimiento de las funciones contenidas en esa librería se usa otra DLL que
es usada por algunas de las funciones contenidas en esa segunda versión. Esa
otra librería puede ser una librería del sistema, la cual a su vez se
actualiza con nueva funcionalidad y puede que dicha funcionalidad dependa a su
vez de una tercera librería.
Resulta que instalamos un programa que usa las últimas versiones de todas estas
librerías. Todo va bien, el programa funciona a las mil maravillas y nosotros
estamos "supersatisfechos" de ese programa que no se cuelga ni una
sola vez... (¿quién habrá hecho ese programa tan maravilloso?, sin
comentarios...)
Ahora llega a nuestras manos otra aplicación que necesitamos instalar y la
instalamos, pero resulta que esa aplicación usa la primera versión de nuestra
famosa librería. Si el programa de instalación está bien hecho, no ocurrirá
nada malo, ya que al descubrir que tenemos una versión más reciente de la
librería, deja la que ya está instalada. Probamos el programilla de marras y
todo funciona bien. Probamos el maravilloso programa anterior y también
funciona bien. ¿Cual es el problema? Por ahora ninguno, pero espera...
Después instalamos un programa que usa una de las librerías del sistema u otra
que también usa nuestra "flamante" librería, pero ese programa se ha
instalado de "mala manera", bien porque el programa de instalación
sea una caca o bien porque simplemente se ha instalado mal... como quiera que ha
instalado una librería anterior a la que nuestros dos maravillosos ejecutables
usan, se puede dar el caso de que ninguno de los dos programas funcionen
correctamente... esto ocurrió cuando salió el Internet Explorer 4 y a más de
uno nos trajo de cabeza, aunque también ha ocurrido con otros programas que no
han tenido en cuenta a la hora de instalar que ya existe una versión más
reciente de la librería. Por suerte, esto ya es menos común que hace unos
años, sobre todo si los programas de instalación están creados con el Windows
Installer o estamos usando el Windows 2000/XP.
Pero es que .NET mejora aún esa "imposibilidad" de meter la pata ya
que cada assembly contiene un manifiesto en el cual se indica:
-el nombre y la versión del assembly,
-si este assembly depende de otros ensamblados, con lo cual se indica hasta la
versión de dichos ensamblados,
-los tipos expuestos por el assembly (clases, etc.),
-permisos de seguridad para los distintos tipos contenidos en el assembly.
También se incluyen en los assemblies los datos del copyright, etc.
Nuevamente he de decirte que no
debes preocuparte demasiado por esto, ya que es el propio .NET el que se encarga
de que todo funciones a las mil maravillas, o al menos esa es la intención.
La ventaja de los ensamblados
es que "realmente" no necesitan de una instalación y un registro
correcto en el registro del sistema de Windows, ya que es el
"intérprete" de .NET el que se encarga de hacer las comprobaciones
cuando tiene que hacerlas. Por tanto podríamos distribuir una aplicación sin
necesidad de crear un programa de instalación. Pero, (¿por qué siempre hay un
pero?), si la aplicación usa ensamblados compartidos, puede que sea necesario
usar una instalación.
Los ensamblados compartidos se pueden usar por varias aplicaciones diferentes y
deben estar "debidamente" instalados en el directorio asignado por el
propio .NET Framework.
Ejemplo de ensamblados compartidos son los que definen las clases (tipos) usados
por el propio .NET Framework.
Para terminar esta primera
entrega introductoria al mundo .NET vamos a ver algunos conceptos que usaremos
con bastante frecuencia en el resto de las entregas:
Nota:
Las palabras o conceptos están en la página del
glosario.
Y hasta aquí hemos llegado en
esta primera entrega del Curso de iniciación a la programación con Visual
Basic .NET
Nos vemos.
Guillermo
Esta entrega ha sido escrita en
varios periodos de tiempo, empezándose el día 8 de Septiembre y terminándose
el 12 de Octubre de 2001, aunque no he estado todo ese mes y pico escribiendo,
que tampoco ese eso.