Aula Macedonia


Curso de Programación Visual en Delphi


Artículo realizado por
José Antonio Suárez.





Capítulo2.
La Historia de Delphi




Delphi es el descendiente de Turbo Pascal, uno de los lenguajes más populares de la década de los 80 en el entorno de desarrollo de aplicaciones importantes en PC (al igual que C).

Fue creado por Borland International y salió a la luz a principios de 1995 con el propósito de unirse a la ola de herramientas de programación visuales, justo en el momento en que Microsoft Visual Basic 3.0 era el rey, y al que no tardó en desbancar.

El motivo de su superioridad se basaba en que era un compilador y no un intérprete de pseudocódigo

(p-code) como Visual Basic. Su biblioteca de controles visuale (VCL) cubría todo lo necesario para la programación en Windows 3.1, añadiendo innumerables facilidades de uso, e incluso permitía crear nuestros propios controles y añadirlos a la librería, algo tan solo posible con los compiladores de C.

El lenguaje de Delphi se apoyó en Object Oriented Pascal, conformando un verdadero lenguaje orientado a objetos llamado Object Pascal.

Por esto, y teniendo en cuenta que pertenecía a Borland, la empresa de lenguajes de programación por excelencia, parecía que podía equipararse incluso a los compiladores de C++, verdaderos reyes internacionales de la programación profesional en ese momento, y de hecho así fue y continua siendo en estos momentos en los que todo lo demás cede terreno a velocidades alarmantes ante el Delphi (y ante el Java).

Actualmente existen 3 versiones fundamentales de Delphi: Delphi 1 para Windows 3.1 y Windows 3.11, y Delphi 2, junto a Delphi 3, para Windows 95-Windows NT.

Su situación en el mercado es inmejorable, ya que cuenta con miles de páginas WEB, cientos de servidores dedicados exclusivamente a él, así como innumerables Foros de Debates, Sitios de FTP plagados de librerías, Chats e IRCs donde sólo se discute sobre Delphi, Servidores de News… y todo lo que pueda darse a través de Internet, además de una extensísima bibliografía internacional, con o que cualquier programador avanzado podrá buscar ayuda en cualquier sitio, resolver dudas compartiendo sus conocimientos con miles de programadores como él. Incluso para los que se inician en el mundo de Delphi, todo esto es un añadido más para que caiga en las redes de esta increíble plataforma de desarrollo, que hace que la programación de aplicaciones de verdad sea lo más asequible posible.

Pero no nos dejemos llevar por la euforia, no todo van a ser facilidades.

 

2. Requisitos para aprender Delphi

Los compiladores de Delphi ofrecen toda la potencia que una máquina apoyada en Windows puede ofrecer sin que ningún otro entorno se le acerque desde lejos (tan solo el de Visual Basic 5 se puede comparar al del Delphi 3, perdiendo por muy poco… pero como sigue siendo Basic…). Pero es necesario poner de parte del programador el tiempo y el esfuerzo necesario para convertirse en un verdadero profesional de la programación mediante Delphi, ya que la mejor herramienta no hace al artista.

Hasta el momento tan sólo un lenguaje (de los que verdaderamente sirven) es más fácil de aprender que Delphi. Este lenguaje es el Visual Basic, por supuesto. Pero ¿para qué utilizar un lenguaje si cuando se quiere hacer algo de verdad nos encontramos limitados por su falta de potencia?

Para empezar a aprender Delphi no es necesario ningún conocimiento avanzado en ningún tema (claro que si se tiene, obviamente será mucho mejor).

Si se conoce el lenguaje Pascal, se encontrará con que la sintaxis básica es prácticamente la misma (esto tambien sirve para Modula). Pero si tan sólo se conoce C, el cambio de sintaxis le costará más que a ningún otro porque la flexibilidad, y por qué no decirlo, los verdaderos jeroglíficos que se pueden hacer en C, serán totalmente imposibles debido a la mayor estructuración y rigurosidad del Object Pascal (no creo que exista nunca un concurso en Delphi como el Ofuscated-C, donde el premio es al programa en C más ilegible, más enrevesado y que, por supuesto, haga algo).

Así que lo primero en lo que hay que centrarse es en la sintaxis del lenguaje Object Pascal, pasando posteriormente al aprendizaje de la Programación Orientada a Objetos.

Otro de los puntos fuertes donde insistir es la Orientación a Eventos, debido a que al estar basado en Windows, todo lo que se haga se tendrá que preparar para este "sistema operativo", basándolo todo en el ratón y sus "eventos" como fuente principal de entrada de órdenes.

Habrá que saber qué son los formularios, los botones, las cajas de texto, las listas desplegables, las listas combo, los contenedores de imágenes…; es decir, todas las cosas que conforman Windows y lo convierten en un manejador de eventos (sucesos tales como pulsar el ratón, desplegar una lista, maximizar un formulario, etc).

Pero no hay que alarmarse, ya que, gracias a Delphi, se puede decir sin exagerar que su manejo es un auténtico juego de niños.

Resumiendo: estos son los tres pilares de Delphi:

  • Object Pascal
  • Windows-Orientación a Eventos
  • Orientación a Objetos

En un primer lugar, tan sólo serán necesarios los dos primeros para hacer pequeñas aplicaciones, pero cuando el proyecto a desarrollar sea lo suficientemente importante, el tercer pilar será fundamental. Con esto no se pretende afirmar que sin la orientación a objetos no se pueda conseguir todo, es más, algunos programadores acostumbrados durante toda su vida a la programación funcional no usan los objetos (ni quieren saber nada de ellos). Pero cuando un programador cambia su modo de pensar "funcional" al de "objetos", se puede decir que ha alcanzado el mayor nivel para poder desarrollar con garantías aplicaciones profesionales, rigurosas, reutilizables y rápidas de desarrollar que al fin y al cabo es lo que importa.

A continuación vamos a ver dos partes que nos introducirán en lo que consiste hoy en día la programación a nivel profesional, ya que considero que quizás sea más interesante saber además de los precedentes del lenguaje Delphi expuestos anteriormente, la actualidad en el mundo de la programación.

Por esto, la primera parte va a estar totalmente centrada en:

Programación Orientada a Objetos,

 y la segunda en el Diseño:

Programación Orientada a Eventos,

Entorno de Desarrollo Visual y

Herramienta de Desarrollo Rápido.

 

Pero antes que nada, una aclaración. Lo expuesto no va a estar todo lo rigurosamente que debería si esto fuera dirigido a otro tipo de público, así que como lo que importa es que se entienda, el puritanismo y las formalidad absolutas han sido erradicadas.

 

3. Programación Orientada a Objetos (OOP)

Para situarnos antes que nada, vamos a clasificar los lenguajes de programación en tres categorías:

  1. Funcionales (C, Pascal, Modula2, Basic...)
  2. Declarativos (Lisp, Prolog, Goffer-Haskell...)
  3. Orientados a Objetos (Java, Delphi... ¿C++?)

Delphi se basa en Object Pascal, un lenguaje totalmente orientado a objetos, categoría en la que tan solo se pueden incluir lenguajes tales como Smalltalk (pero que tan solo sirve para el ámbito universitario), Eiffel (siquiera más inútil que el anterior hoy en día), Java (el verdaderamente útil si no se le saca de su terreno: Internet y multiplataformas) y C++ (con este último no me cansaré nunca de decir que es C con una librería de Objetos añadida, por muy potente que sea).

La OO (Orientación a Objetos) hace de Object Pascal un lenguaje muy potente, ya que simplifica en gran medida muchos de los problemas que se plantean en el desarrollo de aplicaciones complejas usando un lenguaje procedural, como pueden ser Pascal, C o Basic. ¿Y por qué esta afirmación? Pues porque cuando los programas que se realizan hoy en día en el mundo profesional dejan de llamarse "programas" para denominarse "Proyectos", la metodología funcional aplicada a un trabajo que raramente se hace ya por una sola persona, practicamente no sirve. Esto se produce en el momento en el que la programación es realizada por un equipo de programadores.

Imaginemos a varias personas programando en C o Pascal sobre un mismo programa, con un resultado final de decenas de miles de líneas de código, centenares de rutinas que seguramente podrán ser reutilizadas en futuros proyectos... y seguro que habrá un montón de esas rutinas que uno de los programadores ha creado y hace prácticamente lo mismo que la de otro compañero, pero que está en módulo distinto al suyo...

Seguro que la coordinación tan sólo se tratará de hacer al final, cuando todas las partes estén terminadas, asegurando cuelgues, cabreos, noches perdidas buscando el maldito bug que hace que al pulsar sobre un simple botón REVIENTE el programa con mensajes tan conocidos como: Abnormal Program Termination, o Stack Overflow (para los amantes del DOS), o los (Exception Halting Error at: 13243:2354:000h in Runtime.DLL, para los programadores de Visual C...)

Y es que ya no vale que se diga: Quiero un programa que haga la gestión de mi VideoClub.

Y que el programador se cree un esquema de todo lo que va a ser el programa, en media hora, para rápida y ávidamente pasar a escribir líneas de código como un descosido.

Es verdad que existen técnicas de desarrollo de proyectos tipo Ingeniería del Software con Ciclos de Vida en Cascada, Desarrollo de Prototipos, incluso Métrica, Diagramas de Flujo de Datos, Diagramas de Arquitectura, Diagramas de Estados... (vamos, lo que se suele dar en 3º o 4º de Informática en nuestras queridas Universidades Españolas).

Estas técnicas sirven para diseñar lo que va a ser el producto final, basándose en las especificaciones del cliente que pide el programa, y que pasarán por sucesivas fases de refinamiento de requisitos hasta que todo quede bien atado y se pueda firmar un contrato que dé lugar al comienzo de la programación.

Pero todas esas técnicas, cuando se basan en la programación funcional, están totalmente desfasadas. Esto ya ha sido más que probado con el mejor método que conoce el hombre para cerciorarse de algo: Tras un año de trabajo, la conclusión sobre el trabajo obtenido es: ¡ESTO NO SIRVE!, o ¡ESTO NO ES LO QUE HABIA PEDIDO!

Así que nadie se desanime si esto es lo que tiene que estudiar porque lo dicen los planes de estudio, ya que en algunos sitios se da tambien el diseño de proyectos basados en Metodología de Objetos, que al final lo que produce es un conjunto de diagramas y esquemas que los programadores tendrán que convertir en código de un lenguaje OO.

Este diseño tiene en común con los anteriores en que los desarrollan analistas especializados en esta tarea, en que se definen una etapas por las que necesariamente se tiene que pasar para alcanzar el final. Pero difieren radicalmente en el planteamiento de las soluciones a los problemas presentados.

En la programación funcional siempre se basa en pensar desde el punto de vista de los procesos, es decir:

¿Que se necesita que se aplique una fórmula sobre un conjunto de datos?

Pues se piensa directamente en la función o procedimiento que lo resuelva.

¿Que se necesita una representación de esos datos en forma de tabla en pantalla?

Pues se hace la pertinente función.

Y esto se aplica a todo, obteniendo al final un conjunto de funciones y procedimientos que resuelven todos los requisitos planteados, para, posteriormente, crearse una rutina principal que las vaya llamando según se necesiten, y haga de interfaz y control. Por supuesto que cualquier proyecto se puede llevar a cabo mediante esta técnica, de hecho así es como se viene haciendo desde que la informática nació hace ya 40 años o más.

Pero pongámonos ahora en el caso de que el macroprograma que se ha conseguido desarrollar ha tenido tanto éxito que vamos a sacar una nueva versión. Lo típico es coger el código antiguo, y comenzar a "trastocar" y "mejorar" todas las rutinas. Pero lo suyo es partir desde cero aplicando la única reutilización de código posible en la programación funcional: Copy-Paste. O sea, coger una función que queremos reutilizar y copiarla en el nuevo programa. Ante esto, se puede tener la seguridad de que será una ardua tarea coger las funciones que estaban preparadas para el código antiguo, que dependían de variables globales para funcionar de una forma u otra, a la que se habían añadido parámetros para poder utilizarla en varios casos distintos, con lo que la dependencia del código alrededor suya era total... y ahora se quiere reutilizar en otro sitio...

Es cierto que existen mejoras a la programación funcional, como por ejemplo, la abstracción, la declaración de variables locales, la modularidad intentando crear cajas negras de las que tan sólo interesa saber qué hacen y nó cómo lo hacen..., pero ha llegado un momento en el que todo esto es insuficiente.

Desde hace varios años y debido a todos estos problemas que provocaron terribles quebraderos de cabeza conforme la complejidad del software aumentaba, comenzó a tomarse en serio lo de la programación OO. No es que naciera hace poco, ya que como tal existe desde hace muchísimos años (el Smalltalk es de los 60-70), sino que al ser una forma de considerar la programación totalmente distinta, fue dejada de lado expresamente.

¿Y qué es lo que puede aportar la programación OO?

Pues en primer lugar, hay que trastocar completamente la forma de representar las cosas. Ahora no vamos a centrarnos en los procesos, funciones y todo lo que sea el funcionamiento del programa desde el punto de vista del ordenador. ¡Ahora vamos a pensar como humanos! Se tendrá que pensar en las cosas como "Objetos", sobre los cuales se van a hacer determinadas operaciones, que en principio van a ser independientes del lugar en el que estén implementados (ya hemos solucionado el problema de la reutilización, algo que de por sí ya sería suficiente para su uso).

Estos objetos van a clasificarse según clases o colecciones, como por ejemplo los objetos: Círculo, Cuadrado, Triángulo, agrupados en la Clase: Figuras.

Así tendremos objetos agrupados en clases, independientes entre sí, que se podrán utilizar en cualquier lugar, que podrán ser modificadas internamente sin que los programas que las utilizan se percaten de ello a no ser que sea para mejor... (bueno, algunas veces las mejoras tan solo son publicidad... como Windows).

 Pues bien, con este repaso de lo que es la OO he intentado plantear como están las cosas desde un punto de vista informal, pero como existen gustos para todo, ahora es necesario que lo expuesto anteriormente sea expresado más formalmente, de modo que los futuros programadores de OO vayan conociendo los nombres propios de esta nueva forma de entender la programación. Pero ahora vamos a ir relacionándolos con Delphi. Estos nombres propios son:

  • Objetos y Clases
  • Encapsulación
  • Herencia y
  • Polimorfismo.
3.1 Objetos y Clases

En Delphi prácticamente todo son objetos, desde un botón hasta un formulario (que son componentes de Delphi).

Existen objetos predefinidos, como los citados componentes, pero nosotros también podemos definir nuestros propios objetos..

Un objeto siempre parte de un molde, al que habitualmente se conoce como Clase. En la definición de esta clase se establecen las características de los objetos y se implementan sus funciones y procedimientos, así como sus variables internas, sus valores inciales, la forma en que van a ser llamados, las partes que son públicas, las partes privadas...

Una vez que se tiene la clase, podemos crear objetos de esa clase, que se llamarán instancias de esa clase. Por ejemplo, dada la clase "Figuras" anterior, si queremos utilizarla, tendremos que hacer una instancia de ella. Puede que esto ahora no se entienda, así que pongamos un ejemplo más claro.

Supongamos la clase "Integer".

Ahora si se pone:

var contador:Integer;

Se puede decir que "contador" es un objeto que es una instancia de la clase "Integer"

3.2 Encapsulación

Se conoce con este nombre a una de las tres principales características de la programación OO. Un objeto contiene en su interior las variables necesarias para almacenar los datos sobre los que va a trabajar, así como los procedimientos y funciones precisas para manipularlos. Ningún código externo al propio objeto puede acceder a sus variables (a menos que se declaren como públicas), lo que evita muchos problemas.

De esta forma el código interno del objeto puede estar seguro de que su contenido no ha sido alterado externamente, y que, por tanto, será válido en cualquier momento

Un objeto desde esta perspectiva, es como una cápsula en la cual están contenidas las herramientas y los materiales necesarios para desempeñar la función que corresponda.

3.3 Herencia

La herencia es la segunda palabra mágica de la orientación a objetos, y seguramente la característica más útil dado que permite ahorrar la escritura de mucho código. Mediante la herencia, es posible definir una nueva clase de objetos a partir de otra que ya existe, quedando todos sus miembros, tanto datos como procedimientos disponibles por la nueva clase. E incluso es posible añadir nuevos miembros a esta clase, ampliando la anterior. De esta forma, la clase nueva va a ser una heredera de la clase padre antigua. Tomará toda su implementación y le añadirá nuevas cosas.

Esto constituye una jerarquía de clases entre padres e hijos que a su vez pueden ser padres de otros hijos, y lo que puede ser la clase inicial totalmente tonta, en los hijos finales se puede convertir en la repera. (¿Se ve la similitud de esto con la evolución humana?)

3.4 Polimorfismo

Seguramente este aspecto es el más incomprendido de la programación OO, pero también es de los más útiles. Un objeto polimórfico es aquel que en tiempo de edición, (cuando estamos escribiendo código), no conoce su tipo (la clase la que pertenece), información que obtiene posteriormente en tiempo de ejecución.

El polimorfismo permite que un programa manipule de una forma homogénea a objetos que son diferentes, ahorrando de paso la escritura de mucho código. Como es lógico, estos objetos deben disponer de una información mínima en tiempo de edición, y van a consumir muchos más recursos que los objetos normales.

Podrá parecer algo muy extraño este tipo de objetos, pero algunas veces son muy útiles.

Y hasta aquí lo concerniente a la OO.

 

4. Desarrollo.

4.1 Programación Orientada a Eventos (EOP)

Para tratar de que esto quede lo más sencillo de entender posible, pongamos un ejemplo de lo que sucede en Windows cuando se pulsa un botón.

Al que usa un programa y simplemente desplaza el cursor hasta ponerlo encima de un control y luego pulsa el botón izquierdo para que se haga una acción, no le importa para nada lo que está sucediendo dentro del programa; lo único que quiere es que lo que se supone que realiza el control se haga cuando se pulse. Pero para los programadores es prácticamente imprescindible saber qué está pasando.

Ante todo, lo primero que hay que tener en cuenta es que se trabaja sobre Windows, es decir, en un entorno donde en cada segundo se generan cientos de mensajes internos, entre todas las cosas que hay en pantalla por un lado, y el propio Windows interiormente por otro.

Los mensajes podemos verlos inicialmente como una especie de cartas que son escritas por un objeto del sistema y enviados a través de un sistema de manejo de mensajes que conforma el núcleo de Windows.

Imaginemos a una persona que escribe una carta, que será un objeto y un mensaje respectivamente. Al enviar la carta, se deja en el servicio de correos (en nuestro caso Windows), para que se encargue de hacer llegar la información a su destinatario o destinatarios.

Ahora pongámosle nombres propios a las cosas.

Supongamos que tenenos un objeto Ratón, un objeto botón, y Windows de por medio.

Supongamos tambien que el botón cambia al color rojo cuando el cursor está sobre él, y que vuelve a su color anterior cuando deja de estarlo.

Cuando se desplaza el cursor sobre la pantalla, el objeto Ratón está continuamente mandando mensajes a Windows para que actualize su posición y se vea donde se debe ver (mientras tanto, el botón está en espera de que pase algo). Pues cuando decidimos poner el cursor del ratón sobre el botón, ocurrirán los siguientes mensajes (hay muchos más, pero ahora nos centramos en los más importantes).

  1. Ratón a Windows: Actualiza mi posición.
  2. Windows a Vídeo: Pon el Cursor en la nueva posición.
  3. Windows a Botón: El Cursor ha entrado en tu zona.
  4. Botón a Windows: Cambia mi color al rojo.
  5. Windows a Vídeo: Pon el Botón en rojo.
  6. Ratón: BOTON IZQUIERDO PULSADO
  7. Ratón a Windows: Botón Izquierdo pulsado.
  8. Windows a Botón: El Ratón ha pulsado con el botón izquierdo sobre tí.
  9. Botón: ORDEN DE EJECUCION.
  10. Botón a Windows: Ejecuta mi código.
  11. Windows a Vídeo: Pon el Botón primero hundido y luego no hundido.
  12. Windows: EJECUTA CODIGO BOTON.

¡Y esto es tan solo un botón, una de las cosas más simples de Windows!

Puede parecer un auténtico follón, pero no hay que alarmarse ya que esto es prácticamente transparente para el programador que use un entorno de programaciín Visual, teniendo tan sólo que preocuparse de escribir el código que tiene que ejecutarse cuando se pulse el botón del ratón sobre el botón de la pantalla. Otra cosa sería si se quisieran hacer efectos de movimiento, cambios de colores y formas…

Podemos pensar ahora que cada vez que movamos el ratón pasarán cosas como esta, y se estará en lo cierto. Y además, tambien hay mensajes internos entre los objetos sin que medie el ratón, o el teclado, por ejemplo la ejecución de aninaciones, de música… en definitiva, de todo.

Pues para que el programador se encargue tan solo de los eventos que le interesen, despreocupándose de los demás, Delphi tiene una forma muy sencilla de hacerlo por nosotros.

Para cada objeto que se suelte sobre un formulario, y tal y como dijimos antes, hay un conjunto de propiedades y un conjunto de procedimientos predefinidos. Pues ahora es el momento de decir que esos procedimientos no son otra cosa que manejadores de los eventos más importantes que se pueden dar en ese objeto, es decir, son procedimientos para responder ante los mensajes de Windows.

Casi todos los objetos tienen en común un conjunto de procedimientos llamados: OnClick, OnMouseDown, OnMouseUp, OnKeyPress, OnKeyDown, OnKeyUp… y tan solo hay que traducir su significado al español para darnos cuenta de su utilidad.

Centrémonos por ejemplo en OnMouseDown.

Si no hacemos nada, cuando a nuestro objeto llegue el cursor y se pulse el botón izquierdo del ratón, Windows le enviará un mensaje indicándoselo y como no hemos dicho qué hacer, nuestro objeto ignorará ese mensaje. Pero si hemos creado código dentro de OnMouseDown, este código se ejecutará siempre que se reciba el mensaje de Windows de que han pulsado sobre él.

Así se puede fácilmente reaccionar ante todo lo que se produzca.

Ahora parece más sencillo ¿no?

Una vez expuesto todo esto, lo que queda por decir en esta parte es qué es la programación orientada a eventos. Es un modo de programar (que se tendrá que tener en cuenta juntamente con la programación orientada a objetos), totalmente distinto al modo tradicional del DOS. Ahora hay que pensar que sólo se va a reaccionar ante la entrada del usuario a través del ratón, teclado o cualquier otro dispositivo, estando mientras tanto nuestro programa inactivo y tan solo respondiendo las partes que se vean afectadas en un determinado momento sin que se pueda decir que hay un procedimiento principal que se encargue del control. Cada objeto se encargará de reaccionar por sí mismo. Vale que su modo de funcionar dependa de lo que se haya hecho previamente, pero es él el que tiene que encargarse de su propio funcionamiento, pudiendo verse todo esto como innumerables islas dentro de la aplicación, que responden tan solo si las cosas van dirigidas hacia ella.

4.2 Entorno de Desarrollo Visual (IDE)

El término Visual se refiere al hecho de que Delphi permite crear aplicaciones "cogiendo" los componentes o elementos que necesitemos y "soltándolos" sobre un formulario de Windows. Pero lo realmente importante es el entorno de desarrollo en su conjunto, ya que como en el fondo un programa Delphi es una colección de objetos (componentes) relacionados entre sí, cuando se "suelte" un botón por ejemplo, sobre un formulario, automáticamente Delphi generará el código necesario para declarar y utilizarlo. Tan solo será necesario (y esto es lo verdaderamente importante) centrarnos en lo que debe hacer el botón cuando se pulse, y no perder el tiempo con declaraciones manuales, petición y liberación de recursos, manejadores de contexto, punteros a estructuras de mensajes…; vamos, todo lo que habría que hacer en Visual C manualmente si queremos salirnos algo de lo común (y eso que es Visual), lo hace el Delphi automáticamente, y aquí es donde está la gran diferencia entre los dos lenguajes.

En resumen, el Entorno Visual de Delphi se encarga de generar automáticamente los manejadores de mensajes de cada objeto, de sus declaraciones, de la importación de las librerías de objetos en las que se encuentran, de permitirnos ver durante la edición el modo en que se va a ver durante la ejecución, algo verdaderamente importante.

4.3 Herramienta de Desarrollo Rápido (RAD)

El conjunto de objetos que nos ofrece Delphi para su uso, junto al entorno visual y su generador automático de código, además de la orientación a objetos, lo hacen idóneo para desarrollar aplicaciones lo más rápidamente posible, ya que se puede diseñar un interfaz (lo que se va a ver externamente del programa) en muy poco tiempo.

Hoy en día, lo que importa es la productividad a la hora de desarrollar software, y si se pierde el poco tiempo que se suele tener para la programación en cosas que son externas al funcionamiento principal de la aplicación, tales como rutinas de manejo de mensajes, manejo de memoria, de dispositivos, el fracaso profesional está asegurado. Por eso, hoy en día, cualquier lenguaje o es Visual o no sirve, así de claro.

Y si además permite la reutilización de código (Delphi, Visual Basic, Visual C, Java), la reprogramación de los objetos que siempre usamos de la misma forma (Delphi, Visual C, Java), el entorno de desarrollo verdaderamente Visual (Delphi, Java, Visual Basic), y la potencia en todos los campos (Delphi), mejor que mejor ¿no?.

5. Algunos ejemplos de programas comerciales desarrollados con Delphi

Para acabar este segundo capítulo, vamos a conocer algunas curiosidades acerca de los programas hechos con Delphi.

El siguiente es un comunicado desde SCOTTS VALLEY, California. 7 de Octubre de 1996

El reciente aterrizaje del U.S. Space Shuttle Atlantis concluyó una excepcional semana para la NASA y Borland International, un líder en el suministro de herramientas de desarrollo de software.

Un mapa computerizado construido con la herramienta Borland Delphi, fue usado en el Atlantis y en la estación espacial rusa Mir mientras orbitaban en una misión de identificación y fotografiado de la Tierra.

La misma semana, otro programa de la NASA desarrollado con Delphi fue galardonado con el premio a la mejor aplicación Cliente/Servidor por InfoWorld Magazine, un líder en la industria de la comunicación de temas informáticos.

Otro ejemplo de uso de Delphi, es el reciente premio nacional al mejor programa español de gestión de control de datos y pacientes oncológicos, otorgado por la SEGO (Sociedad Española de Ginecología y Obstetricia). Este programa se llama CODEON-G (Control de Datos en Oncología Ginecológica) y fue desarrollado por VESALIO Software en 1997 (sí, por si alguien lo ha notado es la empresa donde trabajo, y fui uno de los programadores de CODEON). Esto no pretende ser autopublicidad, ya que lo que es el programa en sí y su codificación, conforman una pequeñísima parte de lo que supone este descomunal proyecto, donde las partes de investigación durante más de 3 años han sido desarrolladas por verdaderos profesionales, tanto informáticos como médicos. Tan solo quiero hacer ver que es posible que mortales como nosotros realicemos programas de calidad sobresaliente en nuestra propia tierra.

Por otro lado, corren también ciertos rumores de que desde la versión 6 de Corel Draw, el código desarrollado en Delphi sustituyó a una buena parte del desarrollado en C, sobre todo la parte concerniente al entorno del usuario e interfaces.

Tambien hay cientos de centros que se dedican al procesamiento de imágenes (sobre todo universidades) que están poco a poco traspasándose a Delphi, aunque si es verdad que las librerías más importantes de este tipo (como las Lead Tools que utilizan Adobe PhotoShop y Corel PhotoPaint) aún son desarrolladas en C, tambien es cierto que comienzan a estar disponibles ficheros de declaraciones, de conversión de tipos y de reutilización de DLLs para su uso en Delphi.

 

Cuelgues Mentales

Como no toda la Informática es seria… ¿acaso no existe Windows 95?

Bueno, a lo que iba, como no toda la informática tiene que ser vista desde el mismo punto de vista, en esta sección que cerrará todos los capítulos de este curso de Delphi voy a poner lo mejor del humor informático que he podido recopilar.

Pero antes quiero dejar claro que no me pertenecen, tan solo las he traducido.

En esta primera ocasión vamos a conocer lo errores de Windows no documentados que Microsoft olvidó poner en sus manuales:

"Windows Error-codes"

WinErr: 001 Windows loaded - Sistema en peligro

WinErr: 002 No Error - Aún…

WinErr: 003 Dynamic linking error - Tu error está ahora en cada fichero que hayas abierto

WinErr: 004 Erronious error - Nada está mal

WinErr: 005 Multitasking attempted - Sistema confuso

WinErr: 006 Malicious error - No muevas el ratón, pero puedes seguir haciendo lo que quieras

WinErr: 007 System price error - Cantidad insuficiente de dinero gastado en tu hardware

WinErr: 008 Broken window - Ten cuidado con los fragmentos del disco duro

WinErr: 009 Horrible bug encountered - Solamente Dios sabe lo que ha pasado

WinErr: 00A Promotional literature overflow - Mailbox lleno

WinErr: 00B Inadeqaute disk space - Libera al menos 1GB para el Sistema Operativo

WinErr: 00C Memory hog error - Se necesita más memoria… más, más, ¡MAS!

WinErr: 00D Window closed - No mires fuera

WinErr: 00E Window open - No mires dentro

WinErr: 00F Unexplained error - Por favor, dinos qué está pasando

WinErr: 010 Reserved for future mistakes by our developers - NO COMMENT

WinErr: 011 Window open - ¡Te he dicho que no mires fuera! ¡A la próxima casco!

WinErr: 012 Window closed - !Te he dicho que no mires dentro! ¡A la próxima casco!

WinErr: 013 Unexpected error - ¿Mande?

WinErr: 014 Keyboard locked - Piensa cualquier otra cosa que se te ocurra y pulsa una tecla

WinErr: 018 Unrecoverable error - El sistema ha sido destruido. Compra uno nuevo

WinErr: 019 User error - No tenemos la culpa ¡No y NO!

WinErr: 01A Operating system overwritten - Por favor, reinstala Windows por primera vez

WinErr: 01B Illegal error - Este error no te está permitido, tienes una falta grave

WinErr: 01C Uncertainty error - Incierto podría ser inadecuado

WinErr: 01D System crash - No creemos que sea culpa de nuestro código

WinErr: 01E Timing error - Por favor, espere… espere hasta que el sistema sea estable

WinErr: 01F Reserved for future mistakes of our developers. - REQUETE NO COMMENT

WinErr: 020 Error recording error codes - Los errores no grabados se perderán

WinErr: 042 Virus error - ¿Como te atreves a instalar OS/2 en otra partición?

WinErr: 079 Mouse not found - Por favor, pulse el botón izquierdo del ratón para continuar

WinErr: 103 Error buffer overflow - Has provocado demasiados errores. Resetea y luego salva

WinErr: 678 This will end your Windows session. - ¿Quieres crear un acceso directo?

WinErr: 683 Time out error - Debes cambiar el procesador, es demasiado lento

WinErr: 815 Insufficient Memory - O tienes 64Mb o no puedes usar el ratón





AULA MACEDONIA
a
MACEDONIA Magazine