Archivo

Archivo para la categoría ‘Artículos’

1 – Introducción a Docker. ¿Qué es y cómo nos puede ayudar?

lunes, 30 de septiembre de 2024 2 comentarios
Share Button

Introducción

La idea es crear una serie de entradas para exponer desde cero, qué es Docker, cómo nos puede ayudar a nosotros como desarrolladores y explicar todo el proceso desde cero hasta poderlo utilizar. Empezaré por la instalación y posteriormente veremos cómo configurar un par de ejemplos diferentes (desde la instalación hasta su utilización).

Para todo esto necesitaremos varias entradas. Os iré completando la lista de links a medida que vaya escribiendo cada una de ellas.

¿Qué es Docker?

Hay muchas definiciones en internet sobre docker, si las revisamos incluyen palabras como, contenedores, virtualización, opensource, plataforma, aplicaciones, imágenes,… Todas ellas tienen que ver con el concepto, pero para empezar a entenderlo tal vez son demasiadas…

Al final, si lo tengo que definir con mis propias palabras de la forma más sencilla posible(y seguramente no será la más correcta), sería algo así como:

«Es una plataforma que me permite ejecutar aplicaciones de forma virtualizada. Sería equivalente a tener una máquina virtual, pero sólo para una aplicación.»

Leer más…

Categories: Aplicación, Artículos, Contenedores, Docker Tags: , ,

RAD Studio XE6 First Look Webminar, Apuntes…

jueves, 17 de abril de 2014 2 comentarios
Share Button


Ayer se celebró por parte de Embarcadero el seminario online de presentación de esta nueva versión de RAD Studio, con título “RAD Studio XE6 First Look Webminar”. Supongo que en breve estará disponible para descarga.

RADXE6-Launch_eDMBanner01_680x150

Un poco tarde para el aviso, pensarán algunos…  ;-)

Cierto, aunque la idea de esta entrada no es para avisar del Webminar, sino para exponer algunas de las cosas que allí se trataron.
En breve embarcadero pondrá a disposición de los usuarios la grabación completa del Webminar (si no lo está ya), así como la transcripción de las preguntas y respuestas.

A esto último voy. A veces estamos atentos a la explicación y nos perdemos (no hay otro remedio) las preguntas y respuestas que se van desarrollando durante el transcurso de la sesión.
Personalmente me gusta guardar la transcripción para revisarla con tranquilidad al acabar, porque es una gran fuente de información y aclaran muchas cosas.

PreguntasRespuestas Del Webminar de ayer he seleccionado algunas; Las he traducido y organizado en secciones. Espero que ayuden a entender (o a aclarar) el funcionamiento de algunas de las novedades que presenta XE6.

Tened en cuenta que la traducción ha sido rápida así que tan vez haya frases que son «mejorables» sintácticamente. También es posible que algunas preguntas/respuestas sean repetitivas, pero las he querido copiar y traducir tal cual sin eliminar ninguna parte ni de la pregunta ni de la respuesta.

Leer más…

Categories: Artículos, Delphi, Eventos, XE6 Tags: , ,

Utilizar ADO con Threads

viernes, 14 de enero de 2011 1 comentario
Share Button

Los threads (o hilos de ejecución), en general, se ven como un tema peliaudo; Son unas «cosas» que están ahí, son buenas (eso dice todo el mundo), pero cuando más se tarde en tener que tacarlos, mejor…  ;-D

Recuerdo que cuando empecé en esto de la programación, los threads o la «programación con múltiples hilos de ejecución» sonaba algo así como «muy difícil». A medida que va pasando el tiempo, uno se da cuenta que que no es así, y cuando has hecho unos cuantos ejemplos te das cuenta de la potencia que aportan y de que realmente sólo hay que tener algunas «precauciones» a la hora de utilizarlos.

En este misma página podéis encontrar algunos ejemplos («ping usando threads», Ejemplo visual y Ejemplo visual ampliado) de programación de hilos de ejecución con Delphi. Ejemplos bastantes sencillos y bastante inútiles, porqué no decirlo, exceptuando la utilidad de aprender cómo funcionan y poder ver un código simple de utilización.

La idea de esta entrada es ir un poco más allá. A veces nos encontramos en una aplicación, con determinadas consultas que tardan mucho tiempo y que no es imprescindible esperar a su finalización para poder continuar con la ejecución normal del programa. Las más comunes serías típicas consultas de Listados, estadísticas o determinadas operaciones que podríamos hacer en 2º plano. Esas consultas serían las candidatas ideales para poder lanzarlas en un Thread independiente del hilo principal del programa.

Para los ejemplos voy a utilizar los componentes ADO y accederemos a la Base de Datos dbdemos.mdb que viene con Delphi.

Para trabajar con ADO utilizando threads, o para lanzar consultas dentro de threads, la única condición es que la conexión (TADOConnection) se cree dentro del mismo thread. Utilizaremos para ello una «cadena de conexión» como propiedad del Thread.

La estructura de la clase podría ser algo así:

TADOSQLThread = class(TThread)
  private
    FADOQ: TADOQuery;
    FSQL: string;
    FTotalTime:string;
  public
    constructor Create(CreateSuspended:Boolean; AConnString:String;
                       ASQL:string);
    destructor Destroy; override;
    procedure Execute(); override;
    property SQL:string read FSQL write FSQL;
    property ADOQ:TADOQuery read FADOQ write FADOQ;
    property TotalTime:string read FTotalTime;
end;

Para lanzar desde una aplicación una consulta utilizando nuestra clase TADOSQLThread , debería bastar con asignar la conexión, la cadena SQL, lanzar nuestro thread y esperar a que acabe. El código podría ser este:

  //crear el Thread; Pasamos los parámetros de conexión y SQL
  th := TADOSQLThread.Create(True, AConnection, ASQL);
  // Evento finalizacion; Al finalizar el control me llegará hasta este evento.
  th.OnTerminate := TerminateThread;
  // Ejecutarlo (ponerlo en marcha)
  th.Resume;

El código operativo del thread es sencillo, se encuentra en el método Execute y lo único que hace es ejecutar la consulta; En el constructor cremos la nueva Query (con una nueva conexión) y asignamos la SQL.

constructor TADOSQLThread.Create(CreateSuspended:Boolean;
           AConnString:String; ASQL:string);
begin
  // Creamos el thread inicialmente suspendido (para asignarle las props.)
  inherited Create(CreateSuspended);
  // No liberar automáticamente
  Self.FreeOnTerminate := False;
  //crea el query
  FADOQ := TAdoquery.Create(nil);
  FADOQ.ConnectionString := AConnString;
  FADOQ.SQL.Add(ASQL);
  Self.FSQL:= ASQL;
end;
 
procedure TADOSQLThread.Execute();
begin
  inherited;
  // Ejecutar la consulta
  Self.FADOQ.Open;
end;

Ahora haría falta probar si en la ejecución de una serie de sentencia SQL con y sin threads se aprecian diferencias visibles. Hay que tener en cuenta que el utilizar o no threads también implica otras cosas.

No todo en este escenario son ventajas, hay que tenerlo en cuenta y entender el funcionamiento para sopesar si en cada caso concreto es beneficioso utilizar threads. Hay 2 grandes inconvenientes que a priori se detectan fácilmente cuando se ejecuta y se prueba un ejemplo como el que vamos a realizar.

Gasto de conexiones: En una ejecución normal, las consultas que se lanzan utilizan todas la misma conexión (ADOConnection); Una premisa que hemos marcado para trabajar con threads, es que cada thread debe funcionar con su conexión propia. Esto implica que en un caso estamos utilizando una única conexión y en el otro X conexiones concurrentes. Esto puede ser un problema en segun qué sistemas.

Sobrecarga de tiempo: El segundo problema (derivado en cierta manera del primero) es la sobrecarga de tiempo que la creación y activación de las nuevas conexiones provoca. Crear, activar (sobre todo este) y liberar las conexiones de cada thread es un tiempo añadido que hay que tener en cuenta.

Estos 2 problemas no se puede solucionar (del todo), pero sí mitigar utilizando un «pool de conexiones«; No es un tema para desarrollar ahora (tal vez más adelante), pero la idea explicada de forma sencilla, es que podemos utilizar un número máximo de conexiones (no tantas como threads). De esta forma, se asigna una conexión libre a un thread cuando la necesita, mientras haya conexiones libres; Cuando ya no quedan libres, el thread debe esperar a que una finalice para que le sea asignada. De esta forma podemos fijar el número máximo de conexiones que se utilizan y además optimizar tiempo, ya que esas conexiones se pueden «reaprovechar» de forma que no exista la necesidad de crear/activar/destruir cada una de ellas.

¿Cuando usar threads y cuando no?

La regla sencilla sería: «Cuanto más grandes y pesadas sean las consultas, más a cuenta sale utilizar threads».

Si lanzamos 20 consultas que tardan muy poco tiempo, el retraso en crear/activar las conexiones de cada una de ellas puede hacer que el tiempo de preparación sea mayor que el de la propia consulta; En ese caso estaremos «gastando» mas tiempo en «preparar» que en «consultar. Por el contrario si esas 20 consultas tardan 30 segundos cada una, el tiempo de extra de conectar para cada una de ellas puede pasar desapercibido (cuando mayor sea el tiempo de consulta, más eficiente este sistema).

Resultado de las pruebas

En las pruebas he lanzado una serie de consultas de forma secuencial. Hay que notar que el tiempo total (para consultas grandes) es sensiblemente menos cuando utilizamos threads; Pero no sólo hay que tener en cuenta el tiempo total, sino el intervalo en que tenemos acceso al resultado de cada consulta.

De forma secuencial, si la primera consulta tarda 10, la segunda 5 y la tercera 7; El tiempo total es de 22, pero los tiempos de acceso a los resultados son 10, 15 y 22 segundos respectívamente; En cambio si esto se hiciera con threads, aun suponiendo que el tiempo total fuera el mismo, los tiempo de acceso a los resultados serían 10, 5 y 7 segundos.

Select * from CustomerSelect * from Employee
Select * from CountrySelect * from items
Select * from Parts

Select * from VendorsSELECT employee.* FROM employee ORDER BY Salary,
LastName DESC , FirstName DESC , HireDate DESC

SELECT employee.* FROM employee ORDER BY Salary DESC

SELECT customer.*, orders.*, items.*, parts.*, vendors.*,
vendors.State, items.Discount, orders.SaleDate, *
FROM vendors INNER JOIN (parts INNER JOIN ((customer INNER JOIN orders
ON customer.CustNo = orders.CustNo)
INNER JOIN items ON orders.OrderNo = items.OrderNo)
ON parts.PartNo = items.PartNo)
ON vendors.VendorNo = parts.VendorNo
ORDER BY vendors.State, items.Discount DESC , orders.SaleDate

La primera prueba consta de una serie de consultas que tardan muy poco tiempo, con la Base de Datos de Access DBDEMOS.MDB (que se adjunta con Delphi). En este caso se puede ver que los tiempos de las consultas individuales son sensíblemente más bajos sin threads que con threads, debido a que las consultas con threads incluyen el tiempo de conexión. Finalmente aunque los tiempos individuales son mayores (con threads) el tiempo total queda bastante igualado (se compensa la ejecución con threads con la pérdida en las conexiones).

DATOS SIN THREADS.

DATOS CON THREADS

¿Qué pasaría si lanzáramos algunas consultas que tarden más tiempo?

Para el ejemplo he utilizado datos propios conectando a SQL Server, ya que los de la Base de Datos DBDEMOS sólo nos sirven para realizar pequeñas pruebas. Os animo a que cambieis la conexión ADO que viene en el ejemplo y configuréis vuestra propia conexión y vuestras propias consultas para realizar las pruebas.

Para la conexión basta con pulsar el botón que aparece en la parte derecha de la conexión:

Y para las consultas,  basta con tener la precaución de colocar el caracter @ al inicio de cada una de las SQL (sólo cuando empieza la consulta, no en el salto de línea).

En este caso, vemos que los resultados sí cambian sensiblemente; Lo primero que nos llama la atención, es la diferencia de tiempo total de la serie de consultas (con y sin threads); He realizado unas cuantas ejecuciones, alternando primero unas y luegos las otras y los resultados de tiempos son estos; Los primeros son las consultas normales y los segundos con threads:

Sin threads:

·············································
Tiempo total(todo): 01:19:359
Tiempo total(todo): 01:18:516
Tiempo total(todo): 01:04:500
Tiempo total(todo): 01:08:969
Tiempo total(todo): 01:09:718
·············································

Con threads:

·············································
Tiempo total con threads(todo): 01:00:000
Tiempo total con threads(todo): 00:46:800
Tiempo total con threads(todo): 00:45:484
Tiempo total con threads(todo): 00:53:078
·············································

Posteriormente he lanzado, para variar, 4 ejecuciones concurrentes de ejemplo; 2 con threads y 2 sin threads y el resultado ha sido similar (en cuanto a la diferencia):

·············································
Tiempo total(todo): 01:48:984
Tiempo total(todo): 01:50:860
·············································
·············································
Tiempo total con threads(todo): 01:27:593
Tiempo total con threads(todo): 01:32:860
·············································

CONCLUSIÓN: Aunque el ejemplo es bastante sencillo, y la clase que implementa los threads tiene poca «chicha» yo creo que se ven las posibilidades de utilizar esta opción. También debe quedar claro que no es algo para usar «siempre»; Hemos visto que dependiendo del escenario donde se utiliza puede resultar inútil e incluso contraproducente, ya que gasta más recursos que la técnica sin threads. Como ventaja tenemos que la utilización de threads, en general, nos aporta paralelismo y mayor control en la ejecución del programa (ya que evitamos el «bloqueo» en el caso de una consulta muy costosa).

El código fuente del ejemplo, el binario podeís descargarlo desde aquí.

<DESCARGAR CODIGO FUENTE>

Un saludo.

 
Categories: Artículos, Delphi, OOP Tags: , ,

Sistema de PlugIns en Delphi – Parte 2

viernes, 13 de noviembre de 2009 19 comentarios
Share Button

Pues ha llovido mucho desde la primera parte de este «articulillo»; Por lo que he visto en los fuentes del ejemplo, lo empecé hace aproximadamente hace 2 años, así que eso es lo que lleva de retardo… ;-)

En ese primer artículo se daba una visión general de lo que podía ser un sistema de PlugIns. Unas ideas generales y algo de código para empezar. Quedaba en el tintero profundizar un poco más en el tema y ver un ejemplo un poco más «práctico» que pudiera servir en una aplicación real. Eso es lo que he intentado tratar en esta segunda parte, centrandome en un sistema de «PlugIns Homogéneos«, con carga bajo petición (por parte del usuario).

TIPOS DE PLUGINS

Como ya vimos en la primera entrega, podemos dividir los plugIns en dos tipos según las tareas que desempeñan en una aplicación. Así podemos hablar de plugIns o grupos de ellos y catalogarlos como homogéneos si la tarea que realizan es similar o catalogarlos como heterogéneos (no-agrupados) si las tareas que desarrollan son independientes y no “agrupables” según su funcionalidad.

  • Grupos homogéneos de PlugIns
  • PlugIns heterogéneos

Esta división no sólo es conceptual en función de las características y desempeños de cada uno, sino que afecta directamente a la estructura con que se diseñarán estos elementos. Así, los PlugIns que pertenezcan a un grupo homogéneo tendrán estructura similar y un punto de entrada común (formulario base o procedimiento de ejecución). Mientras que los heterogéneos posiblemente no tengan una estructura común y la forma se ejecutarlos sea más “tosca” y menos “integrada” que los anteriores.

PLUGINS HOMOGENEOS

En este artículo vamos a tratar más profundamente esta variante de plugIns. Como ya hemos comentado se trata de plugIns con una estructura similar, aunque con variaciones en su funcionalidad. Tal vez con un ejemplo se vea más claro.

Tomemos como grupo homogéneo de PlugIns; Los efectos aplicables a una imagen dentro de un programa de diseño. A partir de una imagen podemos desarrollar plugIns que efectúen un determinado “cambio” de forma que la imagen resultante sea diferente a la original. La estructura y los parámetros de todos ellos parece claro que serán similares o idénticos. Todos ellos toman una imagen inicial y a partir de unos parámetros la modifican, para devolver una imagen de salida.

ESTRUCTURA FÍSICA

Para trabajar con esta estructura de plugins, utilizaremos un sistema de carga dinámica. Los plugins de programarán utilizando packages (BPL) con una estructura común y dependiendo de un package principal que contiene la Clase Base. Todos los plugins derivarán (heredarán) de una clase base que estará programada en el package principal.

Al cargar la aplicación se carga (puesto que está linkado de forma estática -utilizando la clausula USES-) también el package correspondiente a la clase Base. Esto da acceso a todos los métodos que estén definidos en la clase base (y en los derivados) desde el programa principal.

El resto de packages se cargan de forma dinámica y todos deben derivar (sus clases) de la Clase Base programada en el package Base.

PROTOTIPO

El prototipo que vamos a realizar para ilustrar el artículo simula un programa para realizar gráficos y diagramas simples. El programa utilizará un sistema de plugIns para añadir bibliotecas de objetos que puedan añadirse a los gráficos. Cada pluging (BPL) añade una nueva categoría de elementos y cada categoría implementa uno o varios objetos.

Todos los objetos que implementa una categoría derivan de una Clase Base (TShapeExBase) y esta clase base se implementa en un package que está linkado estáticamente a la aplicación principal (se carga siempre al arrancar la aplicación) y es obligatorio que exista, de otra forma la aplicación fallaría al ejecutarse.

En la imagen que se ve ala derecha, vemos la ventana correspondiente al Plugin de «Arrows»; Aquí implementa la clase TShapeExArrow (que deriva de TShapeExBase) y en esta clase se han programado los objetos que se ven en la imagen.

En nuestro ejemplo para este artículo se cargan los plugIns bajo petición. Es decir, en una primera pasada la aplicación revisa la existencia de PlugIns y detecta todos los ficheros presentes. Muestra una ventana con los plugns disponibles y la descripción de cada uno de ellos y a medida que el usuario los selecciona se cargan de forma dinámica. Imagen de la derecha.

El código de la carga es el siguiente:

...
  // Comprobación
  if not FileExists(AName) then begin
    _mens(Format('No se ha podido cargar el package &lt;%s&gt;;' +
        'No existe en disco.',[AName]));
    Exit;
  end;
 
  // Cargar
  hndl := LoadPackage(AName);
  desc := GetPackageDescription(PChar(AName));
  Result := hndl;
 
  // Acceder a la clase del menu
  pName := ChangeFileExt(ExtractFileName(AName), '');
  b := ExClassList.Find(pName, i);
  // Encontrada?
  if (b) then begin
    AClass := TPersistentClass(ExClassList.Objects[i]);
  end;

CLASE BASE (TShapeExBase)

La clase base para nuestro sistema de plugins se llama TShapeExBase. Esta clase sirve como punto de partida para todas las demás. Además de contener los métodos comunes a todos los plugins nos permitirá acceder desde la aplicación principal a todas las funciones de los plugins. Para ello los métodos importantes estarán definidos en esta clase y luego sobreescritos (override) en las clases derivadas.

{: Clase base lapa las clases implementadas en los plugins.}
  TShapeExBase = class(TShape)
  private
    FShapeEx: string;
 
    // Marca el tipo de Shape
    procedure SetShapeEx(const Value: string); virtual;
 
  protected
    W, H, S: Integer;
    X, Y:Integer;
    XW, YH:Integer;
    W2, H2, W3, H3, H4, W4, H8, W8, W16, H16:Integer;
 
    // Método de pintado
    procedure Paint; override;
    procedure CalculateData();
 
    // PROCEDIMIENTOS DE INFORMACION
    //············································
    // Autor del package
    function Autor():string; virtual; abstract;
    // Versión del Package
    function Version():string; virtual; abstract;
    // Fecha de creación
    function FechaCreacion():TDate; virtual; abstract;
 
  public
    // constructor de la clase
    constructor Create(AOwner: TComponent); override;
    // destructor de la clase
    destructor Destroy; override;
 
  published
    // Tipo de Shape
    property ShapeEx: string read FShapeEx write SetShapeEx;
  end;

En nuestro caso es una clase sencilla. La función implementa el dibujo de componentes derivados de un TShape en pantalla.

La propiedad ShapeEx es la más importante, e indica el tipo (identificador) de la figura. Equivalente a lo que en los TShape son los valores stRectangle, stEllipse, stSquare,…

En nuestra clase no puede ser un elemento tipificado como lo es en TShape, puesto que los nuevos plugins irán añadiendo elementos a esta propiedad que a priori no conocemos.

Se añaden también procedimientos de información acerca del plugin como pueden ser el Autor, la fecha de creación o la versión.

El método Paint, que para la clase base está vacío, en las clases derivadas será donde se implementen las instrucciones de pintado para cada uno de los elementos.

Finalmente la clase Base implementa el procedimiento CalculateData y al utiliza algunas variables en la parte protected, que precalculan datos y los ponen a disposición de las clases derivadas (protected), para facilitar la implementación del método Paint y dar acceso a medidas ya precalculadas.

En la clase Base además se definen dos Listas (TStringList) que nos servirán de apoyo a la hora de acceder a los diferentes objetos de los plugIns; Tanto para las clases, como para los Shapes definidos en cada clase.

  //: Lista de clases registradas en los packages dinámicos
  ExClassList:TStringList;
  //: Lista de objetos registrados en una clase (tipos de Shapes)
  ExShapeList:TStringList;

En la primera añadiremos la referencia a la Clase y el String correspondiente al nombre del package y en la segunda, para cada Shape implementado en la Clase, su valor de la propiedad ShapeEx (comentada anteriormente) y el apuntador a su clase.

De esta forma, por ejemplo, el PlugIn que implementa la clase TshapeExArrow que corresponde a la imagen que se ve más arriba, añadirá en las lista los siguientes valores:

 // Registrar los tipos
  ExShapeList.AddObject('stArrorRight', Pointer(TShapeExArrow));
  ExShapeList.AddObject('stArrorRightW', Pointer(TShapeExArrow));
  ...
  // registrar la clase
  ExClassList.AddObject('PlugArrows', Pointer(TShapeExArrow));

En las líneas anteriores podemos ver que el plugIn PlugArrow (1) tiene implementada la clase TShapeExArrow (1), y que dentro de esta clase hay 6 objetos diferentes de tipo ShapeEx; Cuyos identificadores son: stArrorRight, stArrorRight, stArrorRightM, stArrorLeft, stArrorUp y stArrorDown.

CLASES DERIVADAS

Tal y como está diseñada la estructura, las clases derivadas de la clase Base (TShapeExBase) deben redefinir el método Paint para definir cómo se define cada uno de los objetos de esa clase.

SISTEMA DE CARGA/DESCARGA

El sistema de carga es simple y lo único que hace de especial en este caso es comprobar primero si el package ya ha sido cargado, y si no es así llama a la función CargarPackage del formulario principal, utilizando el nombre del fichero.

Podemos ver por pasos y comentar qué hace esta función:

  // Cargar
  hndl := LoadPackage(AName);
  desc := GetPackageDescription(PChar(AName));
  Result := hndl;

En primer lugar (una vez hemos comprobado que el fichero existe) cargamos el package a partir de su nombre. Una vez cargado obtenemos la Descripción. Para ello se llama a la función GetPackageDescription que se encuentra en la Unidad SysUtils.pas y que develve el valor almacenado en el DPK junto a la directiva {$DESCRIPTION} o {$D} que permite almacenar hasta 255 caracteres.

Todos los packages cuentan con una sección de INITIALIZATION donde añaden a las lista de clases (ExClassList) y a la lista de Shapes (ExShapeList) los elementos que ese package implementa. Estas dos clases son importantes puesto que nos facilitan mucho el trabajo a la hora de realizar todo tipo de operaciones con los elementos de cada packages. Además se registra la clase utilizando el método RegisterClass de Delphi. Por ejemplo, el package de “Arrows” contiene esta sección de INITIALIZATION:

//===================================================================
//
// I N I T I A L I Z A T I O N
//
//===================================================================
initialization
  // Registrar la clase del form
  RegisterClass(TShapeExArrow);
  // Registrar los tipos
  ExShapeList.AddObject('stArrorRight', Pointer(TShapeExArrow));
  ExShapeList.AddObject('stArrorRightW', Pointer(TShapeExArrow));
  ExShapeList.AddObject('stArrorRightM', Pointer(TShapeExArrow));
  ExShapeList.AddObject('stArrorLeft', Pointer(TShapeExArrow));
  ExShapeList.AddObject('stArrorUp', Pointer(TShapeExArrow));
  ExShapeList.AddObject('stArrorDown', Pointer(TShapeExArrow));
  // registrar la clase
  ExClassList.AddObject('PlugArrows', Pointer(TShapeExArrow));
//===================================================================

Lo siguiente que vamos necesitamos, una vez que tenemos cargado el package, es crear la clase que se implementa en el package; Una vez hecho esto ya tendremos total acceso a los métodos que necesitemos y realmente ya habremos conseguido nuestro objetivo.

Para crear la clase utilizamos la lista de clases (ExClassList) que hemos comentado en el párrafo anterior y que hemos rellenado en la sección de inicialización; Otra opción también viable es utilizar GetClass de Delphi mediante RTTI junto con el nombre de la clase registrada (TShapeExArrow). También funcionaría, aunque en este caso, por comodidad, hemos utilizado estas listas auxiliares.

// Crear la clase
  b := ExClassList.Find(pName, i);
  // encontrada?
  if (b) then begin
    AClass := TPersistentClass(ExClassList.Objects[i]);
 
    // OTRA OPCIÓN:
    BClass := GetClass('TShapeExArrow');
  end;

Para finalizar y después de haber realizado unas comprobaciones, llamamos al método CargarCategoria, que crea de forma dinámica la ventana asociada a esa categoría (con la descripción) y también crea el elemento individual asociada a cada Shape implementado en esa clase.

En este punto ya hemos hecho uso de todo lo implementado en ese package, puesto que ya hemos creado un objeto de todos los implementados.

      // Cargar los objetos de ese plugIn
      CargarCategoria(AClass, desc);

En este ejemplo, no descargamos los packages, puesto que los necesitamos para seguir trabajando con los objetos que tenemos en pantalla, lo que hacemos realmente es ocultar la ventana. Si la operación que desempeña el package no necesita que posteriormente esté cargado, bastaría con descargarlo utilizando UnloadPackage.

Hasta aquí las descripción de todo el proceso. Junto con el artículo os adjunto el ejemplo completo y bastante comentado. Es sencillo, pero muestra a la perfección el manejo práctico de este tipo de ficheros.

Espero que haya quedado claro y si hay comentarios o sugerencias, ya sabéis. ¡¡Disparad!!  ;-D

Imagen del programa de ejemplo.

El código del ejemplo se puede descargar desde aquí y los binarios (EXE + BPL’s) desde aquí.

<DESCARGAR CÓDIGO>

<DESCARGAR BINARIOS>

Tal como me comenta Salvador, en el proyecto no se incluyen las dos BPL’s de Dephi (de la VCL) que ne necesitan para ejecutar el proyecto. Si no tenéis Delphi 6 instalado, las necesitaréis para ejecutar. Os coloco los links, con el proyecto (binarios incluyendo las BPLs) y un fichero sólo con los dos ficheros (VCL60.BPL y RTL60.BPL).

<DESCARGAR BINARIOS (Incluyendo VCL60.BPL y RTL60.BPL)>

<FICHEROS VCL60.BPL y RTL60.BPL>

Categories: Artículos, Delphi, Ejemplos, Programación Tags: , , , , ,

Google Maps en Delphi – I

jueves, 14 de mayo de 2009 6 comentarios
Share Button

Después de las dos entradas sobre Codificacióin Geográfica (*), toca entrar de lleno en la Visualización e Integración de Google Maps en nuestro programa, que por otra parte era el objetivo inicial de esta serie de entradas. La Codificación Geográfica (obtención de Latitud y Loingitud a partir de una dirección postal) era un «escollo» a salvar en nuestro camino, hasta nuestro verdadero objetivo.

(*) Lo normal es tener en nuestros programas/aplicaciones una serie de direcciones postales o direcciones de correo que deseamos mostrar o señalar en un Mapa. Para utilizar esas direccones con la API de Google Maps necesitamos obtener las coordenadas de Latitud y Longitud apropiadas. Para ello ya vimos  aquí (Codificación Geográfica – I) y aquí (Codificación Geográfica – II) cómo Google provee métodos para obtener las coordenadas de posicionamiento a partir de direcciones postales.

La idea para conseguir la integración es sencilla. Utilizar un componente TWebBrowser para mostrar una página HTML. Desde Delphi debemos «modificar» esa página para que muestre lo que nosotros deseemos.

Utilizando una sencilla página HTML con un Script, podemos visualizar el mapa correspondiente a coordenadas de Latitud y Longitud.  Con un componente TWebBrowser podemos visualizar esa página dentro de una aplicación delphi.

La página en sí sólo contiene el Script para Visualizar un Mapa.
Dentro del Script vemos cómo se crea un elemento de tipo «map»:

map = new GMap2(document.getElementById("map"));

Se añaden los controles que queremos visualizar en el mapa; En este caso, la selección para el tipo de mapa y control de zoom y posición grande.

        // Controles del mapa
        map.addControl(new GMapTypeControl());
        map.addControl(new GLargeMapControl());

El tipo de mapa que queremos que inicialmente aparezca (Mapa, visión por satélite o lo que Google llama híbrido).

        // Tipo de mapa
        map.setMapType(G_NORMAL_MAP);

Y por último colocamos la posición (latitud y longitud) donde queremos que el mapa salga centrado.

Pero no acaban aquí (ni mucho menos) las posibilidades de Google Maps. Una de las opciones, que dentro de lo sencillo, es muy interesante, es la inclusión de marcas señalando puntos del mapa o incluso ventanas de información no es mucho más complejo.

Para añadir una nueva marca, basta con conocer el punto exacto donde queremos situarla y utilizar un objeto GMarker para mostrarla en el mapa. En cuanto a la ventana, de información, sólo necesitamos el código HTML necesario para crearla.
En este ejemplo la ventana tiene un código sencillo (texto, imagen y link) que se almacena en una variable.

// VENTANA (HTML)
 var html="<img src="http://neftali.clubdelphi.com/images/imagen_neftali_60x54.jpg" alt="" width="60" height="54" />
" + "by Neftalí -Germán Estévez-  2009 <strong>
<a href="http://neftali.clubdelphi.com"
 target="_blank">http://neftali.clubdelphi.com</a>
</strong>
<a href="http://neftali.clubdelphi.com" target="_blank">
    </a>
";

Para mostrarla basta con que utilicemos en método OpenInfoWindowHtml (cuyo nombre es bastante descriptivo, por cierto ;-D ) de la siguiente forma:

    // Visualización de la mrca
    var point = new GLatLng(41.381655,2.122829);
    var marker = new GMarker(point);
    marker.openInfoWindowHtml(html);

Hay más opciones y basta con echarle una vistazo a la API de Google Maps para conocerlas. Además hay muchos ejemplos de utilización que pueden servir para aclarar los conceptos y para ver más cláramente cómo se utilizan los diferentes elementos.

Todo lo visto hasta aquí, está puesto en práctica en un ejemplo Delphi.

Podéis descargar el código completo (incluye EXE -comprimido UPX-) desde aquí:
<Descargar Ejemplo>

Y aquí acabamos esta entrada, que no será la última. Me dejo para una segunda parte, algunos detalles finales, como interactuar con el mapa y obtener datos de él y fusionar los dos conceptos vistos hasta ahora.

Nos vemos.

Categories: Artículos, Delphi, Ejemplos, Programación Tags: , , , , , ,

Sistema de PlugIns en Delphi – Parte 1

lunes, 1 de enero de 2007 3 comentarios
Share Button

Más o menos todo el mundo que está metido un poco en informática y más concretamente en programación tiene una idea de qué es un plugin.
¿Cómo definirlo? Tal vez las primeras palabras que se me ocurren son “añadidos» o “complementos». Si buscamos la traducción del inglés veremos que significa algo así como “enchufar» o “enchufable».
Con ambas cosas ya podemos dar una aproximación en programación. Un plugin (plug-in, addin, add-in, add-on, addon,…) podemos definirlo como: “Un programa o librería que permite ‘enchufarse’ o ‘añadirse’ a otra aplicación y que consigue ‘complementarla’ o darle una ‘funcionalidad añadida’.

En este artículo se da una introducción a cómo poder programar plugIns en Delphi.

También podéis decargar el ejemplo que ilustra este artículo:

Categories: Artículos Tags: ,

Jugando con el portapapeles (artículo)

lunes, 1 de enero de 2007 3 comentarios
Share Button

En La idea de éste artículo es hacer un breve repaso a la clase TClipboard que se implementa en Delphi y las operaciones más básicas que podemos utilizar en nuestros programas relacionadas con el portapapeles de Windows. Espero que las explicaciones y los ejemplos aclaren (un poco al menos) el funcionamiento básico sobre éste tema.

Éste artículo apareció en el número 17 de la revista síntesis (muy recomendable por cierto) y de la que se pueden bajar los todos los números desde el Grupo Albor.

También se pueden descargar los ejemplos que acompañan al artículo:

Categories: Artículos Tags: , , ,