En Windows, no son las aplicaciones quienes manejan los recursos del sistema como pueden ser la memoria, los ficheros, las ventanas y hasta los controles gráficos. Es el sistema operativo quién realiza todas estas tareas. Y la aplicación se limita a realizar peticiones de lo que necesita. Estas peticiones se realizan mediante lo que se denomina la API de Windows, que es un conjunto de funciones que proporciona el sistema operativo para poder habilitar la comunicación. Pero este conjunto de funciones es muy grande, poco estructurado y difícil de manejar.
Por todo esto es que los entornos de programación visuales, en su afán de aportar simplicidad y estructuración a la programación en Windows, han desarrollado diversos Marcos de Trabajo. Un marco de trabajo es una fase intermedia que se coloca por encima de la API para aportar mayor sencillez a las aplicaciones. Normalmente estos marcos de trabajo son orientados a objetos y se implementan como bibliotecas del lenguaje base, por ello también se suelen denominar bibliotecas de clases.
La VCL es un marco de trabajo visual y orientado a objetos.
Tan importantes son los marcos de trabajo, que dominar un entorno de programación visual, suele traducirse en conocer el leguaje base del entorno, y su marco de trabajo.
Los marcos de trabajo se pueden clasificar en dos categorías:
OWL (Object Windows Library o Biblioteca de Objetos para Windows) fue un marco de trabajo desarrollado por Borland e incorporado a los compiladores Borland C++ (versiones 3 y sucesivas) y supuso un importante hito en la programación para Windows por su potencia y facilidad de uso.
Microsoft desarrolló su propio marco de trabajo, el MFC (Microsoft Foundation Class o Biblioteca Fundamental de Clases de Microsoft) y lo incorporó a los compiladores Microsoft Visual C++ (actualmente incluso en Borland C++ 5). MFC es una biblioteca de clases menos abstracta que el OWL y más cercana a la API. También resulta más sencillo que OWL para los programadores que conocen la API.
Aunque MFC se usa más que OWL (Microsoft...) la arquitectura de OWL es, técnicamente, mejor que MFC.
En 1995, Borland lanzó al mercado Delphi, que supuso la revolución en la programación para Windows e inició el desarrollo rápido y sencillo de aplicaciones visuales. Delphi ofrecía el desarrollo rápido de aplicaciones (RAD) empleando componentes (objetos que pueden ubicarse en formularios y manipulados por medio de propiedades, métodos y eventos). Esta forma de trabajo se hizo más popular con Visual Basic. Delphi empleaba como base al lenguaje Object Pascal (una ampliación de Pascal que incorpora programación orienta a objetos) y permitía la creación de programas ejecutables independientes que no requerían intérprete, por lo que se ejecutaban mucho más rápido que los de Visual Basic.
Lo más relevante desde el punto de vista técnico es que Borland creó la VCL (Visual Class Library o Biblioteca de Componentes Visuales) que es un marco de trabajo para crear aplicaciones Windows diseñada en torno al concepto de componente (propiedades, métodos y eventos). La VCL desarrollada para Delphi es la misma que se emplea como núcleo de C++ Builder, de hecho, está escrita en Object Pascal...
La VCL hace un uso extensivo del concepto de herencia. El objetivo final de la VCL es crear clases que representan a componentes, aunque algunas clases no hagan referencia componentes concretos: realizan tareas de gestión interna y se emplean como clases bases para derivar mediante herencia otras clases. En la figura 4.2 mostramos una pequeña parte de la jerarquía de clases que forman la VCL. En las secciones 4.1, 4.2 y 4.3 describimos con más detalle las clases más importantes de la VCL.
4.1. Un paseo por la VCL
Conocer en profundidad la VCL se nos antoja imposible, además de innecesario. Es posible construir aplicaciones Windows de gran calidad con C++ Builder sin un conocimiento exhaustivo de la VCL, aunque consideramos conveniente relizar una somera descripción de la jerarquía de clases que conforman la VCL.
Las clases que conforman la parte superior de la
jerarquía de la VCL (TObject,
TPersistent y TComponent) se denominan
clases "abstractas" porque sirven para estructurar,
y agrupar comportamientos comunes de las clases de la VCL.
No se suelen crear objetos directamente a partir de ellas.
Rigurosamente hablando, no son clases abstractas,
porque no tienen métodos virtuales puros (ver sección
5.5.2), pero las podemos
considerar como tales en la práctica.
TObject
Es el ancestro de todas las clases de la VCL. Encapsula el comportamiento común de los objetos en C++ Builder, como puede ser información de la clase, instanciación...
Suele ser una buena idea derivar nuestras propias clases de TObject, porque aunque no sea normal que el programador haga uso de los métodos proporcionados por TObject, si lo es que lo haga C++ Builder en tiempo de ejecución.
Directamente de TObject heredan aquellas clases que no son componentes, y no necesitan ser almacenadas en disco.
TPersistent
Esta clase tiene que ver con la habilidad de un objeto de almacenarse en disco o en memoria, asignarse a otros objetos, así como otros detalles internos de C++ Builder que no es preciso conocer.
TComponent
Ésta es una de las clases más importantes
de la VCL, ya que la mayoría de los objetos
que se manejan en una aplicación son componentes.
Esta clase proporciona toda la funcionalidad que requiere
un componente básico.
La funcionalidad de TComponent
permite que los objetos aparezcan en la paleta de
componentes y que sean manipulados por el diseñador
de formularios, además de otras capacidades
comunes a los componentes.
Los componentes no visuales derivan directamente de TComponent mientras que los componentes visuales derivan de TControl, que a su vez deriva de TComponent. Por esta razón se suelen denominar controles a los componentes visuales.
TControl
Proporciona la funcionalidad de los componentes visuales (controles). Esta funcionalidad es principalmente el aspecto visual que deben ofrecer los componentes en tiempo de ejecución. TControl proporciona mayor funcionalidad que la que requieren los componentes visuales: los componentes individuales derivan de TGraphicControl o de TWinControl, clases derivadas de TControl.
TGraphicControl
Generaliza a los controles que tienen una representación visual, pero no pueden recibir el foco: el usuario podrá verlos pero no interactuar con ellos. Suelen ser controles para visualizar texto (no editable en tiempo de ejecución), gráficos o dibujos. Poseen una propiedad Canvas que permite acceder a su área de dibujo.
TWinControl
Son los controles típicos de Windows, que pueden recibir el foco, contener otros controles, y además poseen un manejador de ventana. Un manejador de ventana es un identificador que proporciona Windows para el control, por lo que podemos decir que Windows tiene un conocimiento directo de la existencia del mismo.
4.2. Clases de Formularios y Aplicaciones
Son controles en si mismas, pero no se presentan en la paleta de componentes.
TApplication
La clase TApplication encapsula una aplicación Windows por lo que caracteriza las operaciones fundamentales de un programa en Windows. TApplication simplifica el interface entre el programador y el sistema operativo, ocupándose de tareas como gestionar el paso de mensajes, proporcionar la ayuda contextual, establecer los textos de sugerencia de los botones y barras de estado, procesamiento de "teclas rápidas", gestión de excepciones, ejecutar cuadros de mensajes, etc.
![]() |
Todas las aplicaciones de C++ Builder tienen un puntero a un objeto TApplication denominado Application, que se crea automáticamente. |
Como Application se crea automáticamente no aparece en la paleta de componentes ni está disponible en el inspector de objetos para manipular "visualmente" sus propiedades. En cualquier caso, algunas propiedades pueden establecerse en tiempo de diseño seleccionando las páginas Forms o Applicaction después de seleccionar Project | Options.
![]() |
Propiedades, métodos y eventos de aplicaciones. |
TForm
La clase TForm caracteriza a los formularios en la VCL. Los formularios se emplean como ventanas principales, cuadros de diálogo, ventanas secundarias o cualquier otro tipo de ventana que se pueda imaginar.
![]() |
Propiedades, métodos y eventos de formularios. |
4.3. Clases de componentes
Este grupo abarca un amplio espectro de clases. Básicamente, incorpora a todos los componentes que aparecen en la paleta de componentes del IDE de C++ Builder (ver sección 3.1) lo que implica que se pueden colocar sobre un formulario.
![]() |
Lista completa de componentes, agrupados por páginas. |
![]() |
Propiedades, métodos y eventos de componentes. |
4.4. Restricciones al uso de la VCL en C++ Builder
La VCL se desarrolló originariamente en y para Delphi, por lo que está construida en Object Pascal. Aunque esto no supone normalmente consideraciones especiales, existen algunos aspectos que deben ser tenidos en cuenta:
4.5. Ejercicios: Pizarra, Controles de edición y Editor.