domingo, 19 de enero de 2014

La programación visual

A diferencia de la programación convencional de computadoras “a la antigüita” en la cual las instrucciones eran proporcionadas a la computadora digital en algún lenguaje ensamblador o en algún lenguaje de alto nivel usando un editor de texto y siguiendo una sintaxis rígida bajo reglas gramaticales inflexibles, algo a lo cual los primeros programadores estaban acostumbrados cuando toda la interacción con la máquina era en el mejor de los casos a través de una terminal con una pantalla con caracteres de texto puestos sobre un fondo negro (la manera de obtener una salida de la computadora al entregar ésta sus resultados) así como un teclado (la manera de dar entrada de datos o de un programa a la computadora), o en el peor de los casos a través de tarjetas perforadas con las instrucciones del programa que tenían que ser entregadas por el programador a los técnicos encargados de la máquina para ser ejecutadas por la computadora -algo típico en la elaboración y ejecución de programas en algún lenguaje como BASIC-; el desarrollo de computadoras personales recurriendo no a una interfaz basada en líneas de texto sino a una interfaz gráfica como los entornos a los cuales estamos acostumbrados hoy en día en sistemas operativos como Windows, Linux y Android ha requerido una reinvención casi total de la manera en la cual programamos las computadoras.

Supóngase que se quiere desarrollar una aplicación sencilla para pedirle al usuario un número con la finalidad de entregarle al usaurio el cuadrado del número. Lo fácil es escribir la rutina para elevar el número al cuadrado, ya que todo lo que hay que hacer es multiplicar el número por sí mismo, lo cual podemos llevar a cabo con unas cuantas instrucciones en lenguaje de máquina. Lo complicado radica en la manera en la cual, bajo una interfaz gráfica, le vamos a proporcionar el dato a la computadora (el número que será elevado al cuadrado). Esto implica de inmediato y en forma segura que se tendrá que crear un programa ejecutable que activado desde algún ícono abrirá una ventana para pedirle al usuario el número que será elevado al cuadrado. Lo cual a su vez requerirá tener que especificar cosas que necesariamente tienen que ser especificadas: ¿De qué tamaño va a ser la ventana en la cual mediante una caja de diálogo le vamos a pedir al usuario que escriba el número que será elevado al cuadrado? ¿En qué parte de la pantalla (esquina superior izquierda, centro de la pantalla, borde inferior, etc.) será puesta esa caja de diálogo? ¿La ventana con la caja de diálogo será una ventana que siempre aparecerá fija en el mismo lugar o será una ventana relocalizable que el usuario pueda arrastrar de un lado a otro de la pantalla? ¿Habrá alguna línea de texto (por ejemplo, en la parte superior) en un borde de la ventana que le de un nombre a la caja de diálogo o la dejaremos sin nombre alguno? ¿Será susceptible la ventana de ser minimizada (enviada a un borde inferior o lateral de la pantalla) o será una ventana de dimensiones fijas en todo momento? Y esto es apenas el principio de los problemas. Si vamos a especificar el tamaño de la ventana en la cual se abre la caja de diálogo, tenemos que recurrir a una manera de poder medir las dimensiones de algo que se ponga en la pantalla, por ejemplo pixeles (elementos de imagen, cada uno de los “puntitos” individuales con los cuales se forma una imagen grande en la pantalla), de modo tal que podríamos especificar una anchura de 500 pixeles y una altura de 250 pixeles. Pero las dimensiones iniciales que especifiquemos tal vez sean insuficientes, o tal vez sean exageradas y en demasía a lo que se requiere. Y si vamos a estar corrigiendo y redimensionando cada aspecto gráfico del programa, a diferencia de lo que ocurre con un sencillo programa en lenguaje BASIC para el cálculo del cuadrado de un número podemos pasar semanas enteras o inclusive meses para lograr lo que antes podíamos llevar a cabo con un programa que no requería más de cinco minutos de elaboración, lo cual puede resultar frustrante para cualquier programador.

De este modo, para programar una computadora usada dentro de un entorno visual, tenemos que romper definitivamente con el esquema de la programación tradicional basada en la elaboración de líneas de texto, y tenemos que modificar nuestro modo de pensar concibiendo una forma completamente nueva de programar, llegando a lo que puede ser calificado como una programación visual. En una programación visual, en lugar de usar un simple editor de texto para escribir instrucciones, línea por línea, esperamos poder contar con un entorno gráfico que nos proporcione un mínimo de herramientas y objetos con los cuales podamos irle dando a nuestro programa de aplicación ese aspecto visual que queremos proporcionarle cuando sea utilizado por el usuario final en una cómoda interfaz gráfica de usuario GUI (Graphical User Interface). Después de todo, si el usuario recurre a un GUI para usar la computadora, ¿por qué no habría de tener el programador que elabora tales programas su propio entorno de desarrollo integrado IDE (Integrated Development Environment)? Es así como evolucionamos de lo que era el lenguaje BASIC a lo que se puede identificar como un BASIC visual. Esperamos poder incorporar, desde luego, los conceptos que ya se habían asimilado previamente, tales como la forma de estipular transferencias condicionales en la evaluación de algún resultado numérico, el uso de bucles para generar una serie de resultados que sigan cierto patrón, la capacidad de poder definir funciones matemáticas nuevas partiendo de una librería pequeña de funciones matemáticas pre-definidas, y así sucesivamente. Pero a esto se le pondrá un nuevo ropaje para que el usuario final pueda hacer uso del programa de la manera más sencilla y más intuitiva posible.

Para irnos dando una idea de lo que es la programación visual, se reproducirá aquí la ventana principal de lo que en su momento Microsoft liberó como su producto Visual Basic 3.0 cuyas versiones posteriores han conservado la misma filosofía de programación (en donde ello sea aplicable, se recomienda ir ampliando las imágenes que serán presentadas para poder apreciar mejor los detalles):




Obsérvese que de modo automático se pone en el escritorio del entorno una ventana llamada Form 1. Esta es la primera forma en la que se trabajará. Obsérvese también que en el extremo izquierdo aparece una tablilla con varios íconos que representan lo que se conoce como controles; se trata de lo que se conoce como la Caja de Herramientas (Toolbox):




La construcción del programa se lleva a cabo en lo que desde un principio es un proyecto. Para construír el proyecto, empezamos por definir la primera forma introduciéndole de la Caja de Herramientas los controles necesarios. Hecho esto, podemos proceder con la construcción de otras formas.

A continuación se muestra la manera en la cual seleccionando en la Caja de Herramientas el control de botón de comando podemos poner en la forma Form1 un botón de comando designado automáticamente por el entorno como Command1:




Obsérvese que hay unos puntos en la orilla del botón de comando Command1 los cuales permiten con la ayuda del Mouse cambiarle el tamaño al botón que aparece dentro de la forma. Pero no solo podemos cambiarle el tamaño de sus dimensiones rectangulares al botón, también podemos cambiarlo de posición dentro de la forma Form1 e inclusive podemos cambiarle el nombre al botón a otro nombre más representativo de la acción que la activación del botón en el programa final llevará a cabo, algo como OK o como Reiniciar. El nombre del botón es una propiedad del botón, considerado a su vez como un objeto. Las dimensiones rectangulares del botón también son propiedades del objeto botón, o sea su Altura (Height) que puede ser (por ejemplo) de 375 pixeles y su Anchura (Width) que puede ser (por ejemplo) de 975 pixeles. Y de hecho, el botón de comando también tiene otras propiedades. No debe causar asombro por lo tanto que éste objeto tenga un menú visual de sus propiedades accesible desde la línea de menú de Visual Basic precisamente bajo el rubro Properties:




Examinando la lista de las propiedades disponibles para tal control, podemos ver que para dicho control podemos cambiar el color de fondo (BackColor) del control. Podemos cambiar también el texto que aparece dentro del control usando la propiedad de Caption como se muestra en la imagen de arriba de la caja de propiedades. A continuación tenemos un ejemplo de cómo podemos cambiarle el texto interno al botón de comando usando su propiedad Caption:




Inclusive el texto que aparece dentro del control puede ser puesto en letras itálicas cambiando la propiedad FontItalic de False a True. Si además de cambiar el texto que aparece dentro del control queremos cambiar el nombre dado al control para fines de programación, lo hacemos escribiendo el nuevo nombre del control en la propiedad Name.

Yendo más arriba, a la forma Form1 dentro de la cual está incrustado el objeto botón de comando, podemos suponer que dicha forma también puede ser considerada como un objeto y por lo tanto también está especificada en sus características por cierto número de propiedades previamente definidas. Yendo a la lista de propiedades del objeto Form1, encontramos que hay una propiedad Name con la cual podemos cambiarle a la forma su nombre de la siguiente manera:




Además de haber puesto dentro de la forma “Calculadora Financiera” un botónn de comando “Calcular”, podemos poner dentro de la misma una breve etiqueta de texto (Label) que indique brevemente al usuario final algo descriptivo de lo que se llevará a cabo. Y las etiquetas, consideradas como objetos, también tienen sus propiedades:




Todo, absolutamente todo lo que se le pueda cambiar a un control está especificado por sus propiedades. Y  puesto que un control es conceptualizado como un objeto, podemos afirmar lo mismo de una manera más elegante diciendo que todo, absolutamente todo lo que se le pueda cambiar a un objeto está especificado por sus propiedades. Si en lugar de que el botón aparezca en la aplicación final en su posición normal queremos que aparezca girado en un ángulo de 45 grados, podemos constatar con solo ver su lista de propiedades que tal cosa no es posible, porque no aparece en su lista de propiedades ninguna propiedad con la cual se pueda variar la alineación del control con respecto a la horizontal. No podemos hacer más de lo que el objeto nos pueda dar.

Puesto que la forma Form1 con la que empezamos arriba es un objeto (que posee propiedades) dentro de la cual podemos incrustar también otros objetos tales como un botón de comando o una etiqueta (los cuales poseen también propiedades), podemos ver que un objeto puede actuar como contenedor de otros objetos, los cuales pueden actuar también como contenedores de otros objetos, y cada uno de los objetos está plenamente especificado por sus propias propiedades.

Quien haya entendido lo anterior, habrá comprendido la esencia de uno de los conceptos más importantes en la programación  moderna, la programación-orientada-a-objetos (Object Oriented Programming), un concepto con el cual algunos batallan tanto que después de haber concluído una licenciatura en informática se ven en la necesidad de continuar con una Maestría tan solo para poder entender bien lo que es la programación-orientada-a-objetos. En realidad, el concepto no es tan difícil de entender, de hecho realmente es sumamente sencillo, tan sencillo que inclusive por eso mismo tal vez muchos lo encuentran difícil de comprender de buenas a primeras.

En el ejemplo dado arriba, se fue construyendo en etapas sucesivas lo que parece ser una Calculadora Financiera. Si realmente va a ser una calculadora financiera, entonces debe poder llevar a cabo algunos cálculos, como por ejemplo calcular el interés compuesto de un depósito en el banco transcurrido un cierto número de meses. Para ello, debemos poder meter (dentro de la forma) el monto monetario, en alguna cajita de diálogo puesta allí para tales efectos, y en otra cajita el número de meses como el tiempo sobre el cual se llevará a cabo el cálculo. Al fin y al cabo, esto es lo que hace una computadora tradicional, inclusive una simple calculadora de bolsillo recurriendo para ello a una fórmula para el cálculo del interés compuesto. Oprimiendo el botón “Calcular” se debe iniciar el cálculo y la respuesta debe aparecer en algún lugar dentro de la caja que define a la Calculadora Financiera. Pero en todo lo que hemos visto arriba, no parece haber una manera de que se lleve a cabo el cálculo que podemos programar casi de inmediato en algún lenguaje como BASIC. ¿En dónde está la labor de cómputo? Hasta aquí, lo único que hemos estado realizando es la construcción de una interfaz gráfica, cómoda y atractiva para el usuario final, pero no pasa de ser una interfaz gráfica usada como el conducto para la entrada y salida de datos, aunque de cualquier modo se debe apreciar que este modo de interactuar con la computadora es mucho más intuitivo y sencillo que el método tradicional basado en una ventana de líneas de comando. En efecto, al ejecutarse una aplicación bajo una ventana de líneas de comandos lo que se tiene es algo en lo que se va introduciendo información a la computadora de una manera como la que se muestra a continuación:


 Dame tu nombre > Armando Martinez
 Dame tu domicilio > Calle Insurgentes 364   
 Dame tu ciudad >








En cambio, con una interfaz visual, la entrada de datos se puede efectuar en cualquier orden y se pueden editar y corregir los errores cometidos en datos que se hayan introducido:




Pero el dilema persiste. ¿Cómo hacer que la computadora lleve a cabo cálculos de tipo numérico (o de cualquier otra índole) con los datos que se le han ido metiendo?

La salida al dilema es que algunos objetos, por ejemplo el botón de comando, deben ser capaces de poner en marcha una serie de acciones de cómputo que sean capaces de llevar a cabo el cálculo requerido. O sea, deben poder hacer lo que normalmente vendría ejecutando un programa de cómputo tradicional. Esto implica forzosamente que los objetos en un entorno visual no solo deben poseer propiedades, también deben ser capaces de poder responder a un evento tal como la opresión de la tecla “Calcular”. La respuesta al evento de oprimir esta tecla debe poder invocar un programa “a la antigüita” que lleve a cabo el cálculo, para lo cual tomará como entrada un número que será la propiedad de alguna cajita de diálogo (como Monto), tomando tras ésto otro número que será a la vez la propiedad de otra cajita de diálogo (como Meses), y una vez efectuado el cómputo debe ser capaz de modificar la propiedad de texto de alguna cajita de diálogo (como Interes Compuesto) con lo cual en efecto se escribirá la respuesta numérica que se haya obtenido.

Para aclarar lo anterior, supóngase que en una forma se han colocado tres controles del mismo tipo, tres botones de comando. Mientras estamos desarrollando el proyecto, si hacemos clic dentro de  uno de los botones, por ejemplo el botón de comando Command2, aparece ante nosotros una nueva ventana en la que podemos especificar (escribir) el código que será ejecutado:




El código que va a ser escrito por el programador, una subrutina que lleva por nombre:

Command2_Click

va puesto entre las palabras clave Sub y End Sub, además de que se le añade a lo anterior un par de paréntesis entre los cuales se pueden especificar argumentos que se le pueden pasar a la subrutina. Obsérvese que, usando un signo de subrayado (guión bajo), se le ha agregado al nombre del control otro nombre, el nombre del procedimiento (Proc) que distingue al evento bajo el cual será invocado el procedimiento, en este caso un “clic” del Mouse efectuado por el usuario final en el botón de comando indicado. El evento del clic no es el único evento que puede reconocer el objeto botón de comando. Puede reconocer otros eventos, tales como los que señala el manual del usuario para el botón de comando:


Eventos disponibles
para un botón de comandos
Evento Acción
 Click  El botón es seleccionado con el
 Mouse o el teclado
 DragDrop   Un control es depositado en el botón 
 DragOver  Un control es arrastrado sobre el
 botón
 GotFocus  El botón obtiene el enfoque
 KeyDown   Una tecla es oprimida mientras el
 botón tiene el enfoque
 KeyPress  Una tecla es oprimida y su valor
 ASCII es regresado
 KeyUp  Una tecla es liberada mientras el
 botón tiene el enfoque
 LostFocus   El botón pierde el enfoque


La misma forma tiene su propia colección de eventos que pueden ser definidos por el programador, tales como el evento Load. A continuación tenemos una rutina de código para una forma que es parte de un proyecto en etapa de diseño:
' Rutina de inicializacion para una forma
' Fijando las variables a sus valores iniciales

Sub Form_Load ()
BanderaDecimal = False
NumeroOperaciones = 0
UltimaEntrada = "None"
BanderaOperacion = " "
End Sub
Al igual que en otras versiones de Visual Basic, los comentarios empiezan con un apóstrofe (comilla) puesto al principio de cada línea de comentario. Aún sin conocer a fondo los detalles de Visual Basic (y se recuerda que aquí se está dando apenas una visión general para darle una idea al lector sobre cómo trabaja la programación visual), podemos intuír que se está llevando a cabo una inicialización de cuatro variables, con la primera variable BanderaDecimal siendo fijada a un valor lógico de Falso, con la segunda variable NumeroOperaciones siendo fijada a un valor numérico igual al entero cero, con la tercera variable (que es una variable de hilera) UltimaEntrada siendo fijada a la hilera "None" y con la cuarta variable (también una variable de hilera) BanderaOperacion siendo fijada a la hilera de un espacio en blanco.

Al ejecutarse una aplicación de Visual Basic, ésta permanece a la espera de que ocurran eventos antes de llevar a cabo la ejecución de código. Un cierto procedimiento es puesto en marcha cuando es disparado por un evento específico. Visual Basic define grupos de eventos relevantes para cada tipo de control. La mayoría de los eventos son acciones que se llevan a cabo por la persona que usa el programa, acciones tan simples como hacer clic con un botón del Mouse u oprimir una tecla en el teclado. Cada evento tiene un nombre, como Click, Load y GotFocus. El mismo nombre es usado para identificar el procedimiento del evento que Visual Basic utiliza cuando ocurre el evento. Formalmente, el nombre completo del evento para un procedimiento de evento es:

NombreDelObjeto_NombreDelEvento

en donde el NombreDelObjeto identifica a la forma o control que es el objeto de la acción, y el NombreDelEvento identifica el evento que ocurre, requiriendo la sintaxis de Visual Basic que se utilice un signo de subrayado (guión bajo) para separar el NombreDelObjeto del NombreDelEvento. Esto hace posible identificar de inmediato los eventos de procedimientos que aparecen en los listados tales como:

   Calcular_Click
   ImprimirTabla_Click
   BotonOk_Click
   BotonCancelar_Click
   Inicio_GotFocus
   Finalizacion_GotFocus
   Descripcion_GotFocus

Otra cosa que podemos apreciar en el ejemplo dado arriba en el cual dentro de una forma se especificaron tres botones de comando es que un objeto puede contener no solo uno sino varios objetos, y los objetos que contiene pueden ser del mismo tipo aunque con distintos propósitos. Una forma es un objeto, y la forma puede contener tres objetos del mismo tipo, por ejemplo tres botones de comando. Los tres botones surgen de una misma estructura, por así decirlo, poseen un mismo esqueleto. Lo que cambia es la piel que cubre al esqueleto, cuyo color y textura puede variar. Ese esqueleto es lo que conocemos como una clase. Cuando creamos un objeto, en realidad estamos creando una instancia de una clase. una vez creado el primer objeto, podemos crear una segunda instancia del mismo objeto creando otra instancia de la misma clase. Haciendo esto una tercera ocasión, podemos tener tres objetos distintos. Obviamente, cada objeto una vez creado tiene que tener un nombre diferente de otros objetos forjados de la misma clase, ya que de lo contrario la computadora no tendría modo alguno de distinguirlos. Y esto nos lleva a otro concepto interesante. Así como tenemos varios tipos de datos, tales como los enteros numéricos y las hileras de texto, ¿por qué no tratar a los objetos como un nuevo tipo de dato? Si aceptamos tal posibilidad, entonces podemos crear cosas más elaboradas tales como un arreglo (array) de objetos. En tal caso, cada objeto se distinguiría de los demás objetos surgidos de su misma clase mediante el índice numérico anclado a tal objeto, y en una situación así no es necesario darle un nombre distinto a cada objeto (en realidad, cada objeto dentro de un arreglo sigue teniendo un nombre distinto, pero la diferencia la marca el número de índice asignado a cada objeto). Esto tiene la ventaja de que podemos obtener acceso a varios objetos surgidos de la misma clase recurriendo a operaciones de indexación numérica, lo cual resulta sumamente útil cuando se están manejando objetos como los elementos fundamentales de una base de datos. Este concepto resulta extremadamente útil y potente tanto para la programación visual como para los sistemas operativos modernos de naturaleza visual (como Windows) que recurren al manejo de objetos que poseen las mismas características y que son capaces de llevar a cabo el mismo tipo de acciones.

Al cambiarle a un objeto el nombre predeterminado que le dá Visual Basic, con la finalidad de hacer nuestro programa más legible para nuestros propios propósitos (empezando por el hecho de que podemos rebautizar el nombre dado a un control poniéndolo en Castellano), un artificio optativo que no forma parte de Visual Basic en sí pero que resulta sumamente útil para ayudarnos a escribir los procedimientos de las instrucciones que se deben ejecutar es lo que se conoce como la notación húngara propuesta originalmente por Charles Simonyi, un programador de Microsoft, el cual se inspiró para ello en una costumbre usada en su lengua nativa, consistente en prefijarle a un control una, dos o tres letras minúsculas que sean descriptivas de la función que estará llevando a cabo el control en los procedimientos que son elaborados para la ejecución del programa. Cada prefijo es mnemónico con la finalidad de que sea fácil recordarlo. Esto es algo que el usuario final nunca llega a ver, los únicos que lo ven son los programadores del código fuente que llevan a cabo la elaboración de las aplicaciones. Así, si se tiene un control que es un botón de comando llamado “Calcular”, el prefijo que le corresponde a tal botón recurriendo a la notación húngara es “cmd”, y el nombre del botón usado para fines de programación vendría siendo “cmdCalcular”. Del mismo modo, otro botón de comando llamado “OKButton” (presumiblemente para que lo oprima el usuario final aceptando con ello la entrada de cierto dato o la aceptación de cierta condición o condiciones) tendría como nombre completo “cmdOKButton”. La lista básica de prefijos propuestos por Charles Simonyi para Visual Basic es la siguiente (hay otros prefijos, desde luego, los cuales se han ido agregando conforme la lista de controles disponibles para versiones más recientes de Visual Basic ha ido creciendo):


Prefijos de la Notación Hungara
Objeto  Prefijo  Ejemplo
 Form (Forma)  frm  frmCalculadora 
 Check box (Caja de chequeo)  chk  chkOpciones 
 Combo box (Caja combo)  cbo  cboSeleccion 
 Command button
 (Botón de comando) 
cmd  cmdOKButton
 Frame (Marco)  fra  fraRundown
 Grid (Rejilla)  grd  grdTabla
 Horizontal scroll bar
 (Barra de desplazamiento
 horizontal)
hsb  hsbVolumen
 Label (Etiqueta)  lbl  lblHeight
 List box (Caja de listados)  lst  lstArticulos
 Menu mnu  mnuAbrirArchivo 
 OLE Cliente (Cliente OLE )  ole  oleObjeto5
 Text box (Caja de texto)  txt  txtName
 Timer (Temporizador)  tmr  tmrAlarma


Así pues, haciendo uso de la notación húngara, para el procedimiento de evento Click que corresponde a un botón de comando llamado cmdOKButton, podemos tener una porción de código como la que se muestra a continuación:




De este modo, cuando el usuario final oprime dentro de la ventana producida por una forma un botón del tipo OK que especifique aceptación, se ponen en marcha una a una (en orden secuencial) las instrucciones del código dadas entre Sub y End Sub que especifican todo lo que se llevará a cabo:




Podemos ver en la ventana titulada “Personnel Information” (que para el programador cuando empezó su proyecto posiblemente era la forma inicial Form1) que hay un dato ausente, el dato “Address”. Obviamente, por tratarse de un domicilio, queremos que el usuario proporcione esta información antes de continuar procesando los datos. Al no haber dato alguno, se trata de una hilera vacía, y seguramente queremos que al ser detectado el texto en la cajita como un texto vacío se le proporcione al usuario algún mensaje pidiéndole que proporcione la información que seguramente se le olvidó meter (el programador puede también, si quiere, darle al usuario la opción de que deje este casillero o varios casilleros vacíos).

Un “objeto” que en realidad no puede ser considerado como tal (no tiene propiedades que puedan ser controladas o especificadas por el programador) es lo que se conoce como una caja de mensaje, para cuya invocación dentro de una serie instrucciones se recurre a la palabra MsgBox seguida del texto (puesto entre dobles comillas) que queremos que sea mostrado por la caja de mensaje. Así, al ejecutarse una instrucción como la siguiente:

MsgBox "Entrada incorrecta. Intentar de nuevo"

dicha instrucción hará que aparezca una caja de mensaje como la que se muestra a continuación:




Esta caja de mensaje es algo que aparece en la pantalla al momento de ejecutarse la instrucción procedimental que se ha dado arriba. Obsérvese que Visual Basic asigna (en un proyecto que acaba de ser abierto) de modo predeterminado el título “Project1” a la caja de mensaje. Podemos hacer que aparezca otro título en la caja de mensaje en lugar del título predeterminado recurriendo a la sintaxis alterna que inclusive mediante el uso de tres argumentos en lugar de dos permite hacer que aparezca en la caja de mensaje uno de varios tipos de botones o símbolos predeterminados:


MsgBox mensaje, tipo, título

De este modo, la instrucción:

MsgBox "Inicializar el sistema", 48, "Advertencia"

hará que aparezca la siguiente caja de mensaje:




No hemos visto aún como nos la podemos arreglar para que se pueda llevar a cabo la manipulación de datos, por ejemplo una manipulación de tipo numérico, usando para ello objetos mediante los cuales llevamos a cabo la entrada y salida de datos. Para lograr tal cosa, recurrimos a un artificio ingenioso cuyo uso se ha vuelto casi universal en la programación en la cual se manipulan objetos, algo conocido como el operador punto. Podemos tener un objeto tal como una caja de texto (incrustado a su vez dentro de otro objeto, presumiblemente una ventana) en el cual podemos meter un número. Y una propiedad principal de tal objeto debe ser que se pueda especificar mediante dicha propiedad el texto, pudiendo escribirse a voluntad cualquier número (como 73465) o una hilera de caracteres (como “Armando”). Si el objeto se llama txtNombre (empleando la notación húngara) y la propiedad que especifica el texto es la propiedad Text, entonces la “variable” a ser manipulada por código procedimental vendría siendo:

txtNombre.Text

Obsérvese el punto puesto entre el objeto txtNombre y su propiedad Text. Dicho punto es precisamente el operador punto. En el ejemplo que se ha dado arriba, podemos reconocer de inmediato el uso del operador punto para efectuar una operación de comparación lógica:



En la instrucción If-Then que corresponde al código, con la parte condicional If:

If txtName.Text = " "

estamos especificando rigurosamente lo siguiente: “Si la hilera de caracteres contenida como una hilera de texto en la propiedad Text del objeto txtName es una hilera vacía, entonces (Then) póngase en la pantalla una caja de mensaje que diga 'Enter your name', y en caso contrario procédase adelante”.

¿Y cómo habremos de accesar una propiedad de un objeto que a su vez está incrustado dentro de otro objeto? Pues mediante la aplicación repetida del operador punto. Supóngase que queremos accesar la propiedad Texto de un objeto 5 (que llamaremos Objeto5) que está incrustado dentro de otro objeto del tipo forma que llamaremos FormaE.  Entonces, mediante la doble aplicación del operador punto, podemos accesar (y modificar) tal propiedad:

FormaE.Objeto5.Texto

Además de los controles proporcionados de manera predeterminada con cada versión de Visual Basic que ha ido apareciendo, la empresa creadora de tal entorno permitió que otros programadores trabajando en casas de programación independientes de Microsoft pudieran desarrollar nuevos controles (en forma parecida a la manera en la que la empresa IBM, al sacar a la venta sus primeras computadoras caseras, puso ranuras en la tarjeta madre en las cuales se pudieran insertar tarjetas conocidas como add-ons vendidas por fabricantes independientes para poder agregar tarjetas de sonido, tarjetas de módems, tarjetas de redes de área local LAN, etcétera). Los controles custom básicos que se le pueden agregar a Visual Basic tienen las siguientes extensiones:

   VBX.- Visual Basic custom eXtension control

   OCX.- OLE eXtension control

observándose que los controles VBX fueron hechos obsoletos con la introducción de los controles OCX. Así, era posible que una casa independiente de programación pudiera producir un control para posibilitarle al usuario final, por ejemplo, dibujar dentro de una forma alguna imagen elemental, dándole algún nombre pintoresco como TURBOCAD.VBX, actualizado posteriormente como un control TURBOCAD.OCX. La misma empresa Microsoft introdujo una mejora sobre los controles anteriores, a la cual le dió el nombre ActiveX, los cuales, dicho sea de paso, ganaron notoriedad por la enorme facilidad con la que intrusos cibernéticos podían alterarlos para usarlos como portadores de virus informáticos, troyanos y gusanos.

Las versiones tradicionales del lenguaje de programación BASIC están orientadas por procedimientos en lugar de estar orientadas por eventos. En un lenguaje procedimental, un programa consiste de una jerarquía estructurada de procedimientos. En la cima de la estructura está una sección principal de programa que controla que controla la acción haciendo llamadas a los procedimientos del programa (en lenguaje llano, a las subrutinas del programa). En general, la acción sigue un estricto orden secuencial. El programa principal invoca un procedimiento tras otro siguiendo un orden escrito, se le pide primero al usuario (por ejemplo) su nombre, tras ello se le pide su dirección, tras ello se le pide el nombre de la ciudad en la que vive, y así sucesivamente, éste orden no se puede invertir (lo cual resulta sumamente incómodo en caso de cometerse errores), y la ejecución del programa termina cuando se hace la última llamada. En contraste, en un programa visual elaborado mediante un entorno como Visual Basic el orden y la secuencia del programa depende de los eventos que ocurran en el tiempo de la ejecución (run time). Algunos procedimientos de eventos pueden ser invocados muchas veces, cada vez que el usuario lleva a cabo alguna acción y pone en marcha el evento correspondiente. Es posible que algunos procedimientos jamás se ejecuten si el evento anticipado no ocurre jamás. Algunas versiones del lenguaje Basic tradicional (antes del arribo de Windows) le permiten al programador prefijar trampas de eventos que anticipan eventos específicos durante la ejecución de un programa. En este sentido, el programador puede crear programas impulsados por eventos inclusive en versiones previas del lenguaje, pero se tiene que escribir el código para controlar todos los detalles mecánicos del evento. Lo que es nuevo en entornos como Visual Basic es el apareamiento entre los objetos visuales en la pantalla -objetos que se pueden seleccionar para la aplicación sin necesidad de tener que programarlos- y los eventos predefinidos relacionados con tales objetos.

Pese a las diferencias entre Visual Basic y otros BASIC, muchas de las palabras clave, herramientas y procedimientos construídos internamente en Visual Basic son los mismos que en otras versiones. Esto se puede apreciar con la siguiente lista parcial de estructuras de programación y herramientas que el lector reconocerá como idénticas, o casi idénticas, a lo que se encuentra en otros BASIC:
  • Procedimientos y funciones, las dos estructuras usadas para organizar secciones individuales de código.
  • Tipos de datos, numéricos y de hileras, y las operaciones y funciones que se aplican a tales tipos.
  • Variables, nombres que representan valores individuales de datos en un programa.
  • Estructuras de datos, arreglos (arrays) y registros (records) que representan valores múltiples de datos bajo un mismo nombre.
  • Enunciados de asignación para almacenar valores en las variables.
  • Estructuras de control, tales como bucles y decisiones.
  • Procedimientos de archivaje de datos, incluyendo entrada y salida secuencial y de acceso aleatorio.
  • Técnicas para captura de errores.
De este modo, mucho de lo que habían aprendido los programadores tradicionales que estaban acostumbrados a las ventanas de líneas de comandos podían aprovechar dentro de los entornos de la programación visual mucha de su experiencia adquirida previamente en la programación procedimental, y no quedaban tan obsoletos como muchos suponían (y de hecho, muchos conceptos tales como los manejos de las estructuras de datos siguieron siendo tan útiles hoy como ayer, resaltando el valor perenne de la educación cuando se manejan conceptos universales).

No hay que perder de vista el hecho de que lo que forma parte de un proyecto en Visual Basic, y de hecho todo lo que forma parte de cualquier proyecto llevado a cabo en cualquier entorno de programación IDE, es producir un archivo ejecutable (como CALCULADORA.EXE) que pueda ser puesto en marcha fácilmente con un clic del Mouse o tocando un ícono en la pantalla táctil de una tableta electrónica. El archivo ejecutable final es un archivo en código binario (convertido a código binario por un interpretador Visual Basic o por un compilador Visual Basic) que puede ser ejecutado por el procesador CPU de una computadora. Este archivo ejecutable puede invocar, con la ayuda del sistema operativo que está instalado en la máquina (y cuya interfaz visual es la que se encarga de trazar en la pantalla ventanas de diálogo, cajas de mensajes de texto, etcétera), otros archivos, especificando todas las formas, botones de comando, cajas de texto, etiquetas, ventanas, íconos y todo lo demás que le dá al programa ejecutable un aspecto visual. Lo que tiene en estos momentos en sus manos el lector que está leyendo ésto es precisamente un resultado de algo que fue programado usando para ello un entorno visual.

Así pues, tenemos que aceptar inevitablemente el hecho de que el resultado final de una programación visual será algo en lo cual el modelo de programación será un modelo manejado por eventos (en inglés, event-driven programming). En esto resulta útil considerar muchas de las cosas que son manejadas y manipuladas por la computadora como objetos. En la entrada “Antecedentes históricos” ya se había dado un anticipo de esto al hacer hincapié en que dentro de un entorno gráfico Windows varias de las cosas que se tienen puestas en el “Escritorio” (el Desktop, la pantalla principal desde la cual el usuario puede lanzar programas de aplicación y manipular archivos y recursos de su máquina) pueden y deben ser consideradas como objetos de un tipo muy especial, se trata de objetos que poseen datos (llamados formalmente propiedades), que puedenposeer funciones especializadas que se pueden echar a andar desde el mismo objeto (llamadas métodos) y que son capaces de poder responder a eventos iniciados por el usuario a través de manejadores de eventos. Podemos darnos cuenta de que cualquier objeto en Windows posee propiedades (datos) con el solo hecho de posicionar y mantener posicionado el puntero (el cursor en forma de flecha) del mouse dentro del objeto, con lo cual obtendremos las propiedades o datos del objeto (posiblemente sea necesario hacer activa primero la ventana para obtener este tipo de respuesta). A modo de ejemplo, considérese el archivo REGEDIT, un programa ejecutable que forma parte de casi todos los sistemas operativos Windows, ubicado generalmente dentro de la carpeta WINDOWS y cuyo completo incluyendo la extensión que identifica el tipo de archivo es REGEDIT.EXE, de modo tal que se trata de un programa ejecutable. En la carpeta WINDOWS, el ícono representativo de REGEDIT.EXE tiene el siguiente aspecto casi inocuo:


Pero con el solo hecho de posicionar y mantener posicionado el puntero del mouse dentro del ícono del objeto REGEDIT, el sistema operativo responde del siguiente modo proporcionando información relacionada con algunas de las propiedades (datos) del objeto (la descripción del objeto, la fecha y la hora en que fue creado el objeto, la compañía que lo creó):




De este modo, el objeto REGEDIT responde al evento en el cual el mouse fue posicionado dentro del ícono que representa al objeto, dando cuenta de sus propiedades. Para poder proporcionar esta respuesta, se da por hecho de que el objeto REGEDIT contiene, además de propiedades, lo que se conoce como manejadores de eventos. El sistema sistema operativo “sabe” cuando el puntero del Mouse está dentro de un ícono, se da cuenta de ello y responde generando un mensaje de evento. En la figura de arriba, no es el usuario el que genera el mensaje de evento al colocar el puntero del mouse dentro del ícono del archivo REGEDIT, es el sistema operativo el que genera el mensaje de evento, y es el manejador de eventos del objeto el que responde al mensaje de evento que le es proporcionado por el sistema operativo, poniendo en marcha su código interno para proporcionarle al usuario un resumen de las propiedades del objeto. Este código interno del objeto no debe ser confundido con el código del programa REGEDIT.EXE en sí, se trata de cosas diferentes, y entre más pronto tome el lector nota de ello tanto mejor.

Además del evento anterior, podemos poner en marcha otro tipo de respuesta haciendo clic en el botón derecho del mouse mientras mantenemos el puntero del mouse situado dentro del ícono que representa al objeto REGEDIT.EXE:




Obviamente, la respuesta es diferente, ya que se abre una caja con una lista de opciones de las cuales podemos seleccionar una en particular. De nueva cuenta, el objeto REGEDIT responde al evento en el cual se hace clic en el botón derecho del mouse cuando el puntero del mismo está posicionado dentro del ícono que representa al objeto, dando cuenta de lo que se puede hacer con el objeto.

Además de los dos eventos anteriores, podemos poner en marcha otro tipo de respuesta haciendo doble-clic en el botón izquierdo del mouse mientras el usuario mantiene el puntero del mouse situado dentro del ícono que representa al objeto REGEDIT.EXE:




En este caso, el programa ejecutable REGEDIT.EXE es puesto en marcha. Al hacer el usuario doble-clic en el botón izquierdo del mouse mientras el usuario mantiene el puntero del mouse situado dentro del ícono que representa al objeto REGEDIT.EXE, el sistema operativo se da cuenta de ello y responde generando de nueva cuenta un mensaje de evento, echando a andar un programa de Windows conocido como el Registro de Windows.

Todo lo que aparece y es puesto en el Escritorio de la pantalla es un objeto asociado con algún recurso subyacente como una impresora, un disco duro, o una escaneadora. Aunque parezca una sobresimplificación el describir a un sistema operativo como Windows como una gran colección de objetos, los cuales pueden poseer propiedades (datos), métodos (funciones internas para hacer algo con el objeto) y manejadores de eventos, en su quintaesencia podemos considerar que tal descripción es apropiada para lo que está ocurriendo. ¡Hasta los archivos de texto ordinario son objetos!

En una máquina nueva, recién desempacada, al echarla a andar por vez primera el disco duro ya viene con una cierta cantidad de objetos pre-instalados. Después de la primera sesión, el sistema operativo genera algunos objetos nuevos (principalmente archivos de configuración y personalizaciones al sistema de parte del usuario) que son guardados en el disco duro para su uso posterior, tras lo cual conforme el usuario va agregando nuevos archivos o va instalando nuevos programas la cantidad de objetos en el sistema irá creciendo.

Cada objeto hereda lo que conoce y lo que puede hacer de una clase de objeto antecesor. Una clase de objeto es como una plantilla que puede crear un tipo específico de objeto -por ejemplo, un atajo mejor conocido como shortcut. Cada atajo tiene los mismos tipos de datos almacenados en el archivo o la carpeta que representa. También cada atajo hereda el código que necesita para poder actuar sobre tales datos.

Aunque al principio no se de cuenta de ello (eventualmente lo hará conforme vaya ganando experiencia), un programador que recurriendo a la programación visual hace un programa para ser usado dentro de un entorno visual está creando un objeto, y una vez creado el objeto dicho objeto es guardado en forma permanente en algún lado de la computadora como el disco duro o un dispositivo de memoria portátil USB. Hay otros objetos que son creados en forma temporal cuando se abre un programa de aplicación, los cuales son eliminados al cerrarse el programa de aplicación; ejemplo de ello son los archivos temporales creados por procesadores de palabras que van guardando periódicamente en el disco duro copias actualizadas de un documento sobre el cual se está trabajando, de modo tal que si hay un apagón eléctrico u otra situación imprevista no se pierda todo el trabajo realizado.

Podemos elaborar un programa de aplicación usando un entorno de programación como Visual Basic olvidándonos de los miles de detalles internos de lo que ocurre al nivel del lenguaje de máquina. Pero... ¿podemos accesar directamente desde Visual Basic alguna o cualquiera de las instrucciones que son ejecutadas por el hardware en lenguaje de máquina? Para tal cosa, por regla general, no se utiliza un lenguaje visual de alto nivel como Visual Basic, se recurre a otro lenguaje como Visual C, considerado por los programadores de sistemas como un lenguaje ensamblador de alto nivel, elaborándose tales programas en un entorno de desarrollo visual. Estos entornos requieren en forma casi obligada de un Depurador de Errores (Debugger) para probar este tipo de programas en forma simulada, porque cuando un programador mete su mano directamente en los interiores del sistema con tal profundidad resulta sumamente fácil poner instrucciones que son capaces de poder mandar abajo no solo el programa que se está elaborando sino todo el sistema, requiriéndose reinicializar la máquina (si es que se puede, suponiendo que no se haya alterado alguna parte crítica de las rutinas que forman parte del sistema operativo, requiriéndose en caso contrario la reinstalación completa del sistema operativo en el disco duro con la posible pérdida de los datos que se tenían guardados). La elaboración de un programa ejecutable recurriendo para ello a un entorno como Visual Basic y la elaboración de un programa ejecutable usando instrucciones estilo assembler (ensamblador) es lo que distingue la diferencia entre un programador de aplicaciones y un programador de sistemas, cada uno tiene su propia área de especialización, aunque siempre es recomendable tener conocimientos en ámbas áreas y estar al tanto de la manera en la que interactúan entre sí los programas de aplicación destinados al usuario con los programas que manejan directamente los detalles interiores al conjunto de instrucciones del procesador central CPU de la computadora.