Archivo

Archivo para la categoría ‘FireMonkey’

Multi-Threading for TBitmap, TCanvas, and TContext3D

viernes, 7 de abril de 2017 8 comentarios

Mucho se ha hablado de las características de Tokyo en cuanto al soporte de nuevas plataformas. Está claro que la irrupción de Linux entre las plataformas destino de nuestras aplicaciones, es el gran atractivo de esta nueva versión. Otros compañeros de la comunidad han hablado del tema y han publicado vídeos al respecto.

En mi caso voy a hablar de otra de las novedades de la versión Tokyo. Se trata del soporte de multithread para las clases TBitmap, TCanvas y TContext3D en Firemonkey para poder trabajar con un único elemento desde diferentes threads.

Tal y como se explica en el enlace de la wiki, internamente las clases realizan la sincronización de forma automátca, así que aunque no ganemos en rendimiento, si podemos ganar en organización y en claridad a la hora de escribir nuestro código y clases. Imaginad que tenemos que dibujar diferentes objetos o elementos en un TCanvas. Ahora podamos organizar el trabajo en diferentes clases (Threads) que se encarguen de dibujar cada uno de ellos. De otra forma tendríamos que tener un único código o clase donde se dibujaran todos ellos (por lo tanto menos estructurado y organizado).

Leer más…

Gratis, C++Builder® 10.1 Berlin Starter Edition

viernes, 17 de junio de 2016 Sin comentarios

PROMOCIÓN ESPECIAL!!

Hoy (y no se si algunos días más) se puede descargar desde la web de embarcadero la versión Starter de C++ Builder 10.1 Berlín.

ClGAk_cXEAAcHbA

 

Enlace a la página.

Vídeo mostrando las características de esta versión.

Un saludo.

Una quincena más… (30/07/2012)

lunes, 30 de julio de 2012 4 comentarios

imagesRetomando un poco (o eso espero) el ritmo de las entradas, para los que estéis interesados  en FireMonkey y en las posibilidades de realizar animaciones y aplicaciones con características 3D, os remito al canal de youtube de ketufe. Podéis encontrar desde ejemplos sencillos y algunos no tanto. Los videos dan ideas de las diferentes posibilidades a utilizar. Hay mucho material para revisar, ya que el canal cuenta con más de 100 videos.

Aquí podemos encontrar un pequeño tutorial de Document Insight; La herramienta de documentación de DevJet Software que viene incluida de forma gratuita con Delphi XE2. Es una de aquellas cosas que no son fáciles de encontrar en la documentación (o que no encontramos directamente) pero que son tremendamente útiles, para los que desarrollamos componentes y librerías que luego utilizan otros programadores. En estos casos la documentación en necesaria (obligatoria diría yo) y además a la larga significa una mayor eficiencia a la hora de programar.

No hace muchos días de la publicación en la página de Salvador (Delphi básico) de dos entradas dedicadas al componente TTreeView en Firemonkey; Yo diría que indispensables para los que queráis empezar a trabajar con él y entender bien su funcionamiento.

Las dos entradas hacen un completo repaso de este componente de este componente y su utilización en Firemonkey. Las diferencias que existen entre este y su versión en la VCL, repasando propiedades, métodos y distintos comportamientos. Muy recomendable por lo compleja y extensa que es. La explicación es muy clara y podéis descargar los códigos de ejemplo para poder realizar las pruebas sin problemas. No os desvelo más del contenido del artículo, que lo hay, os invito a que lo reviséis completo. ;-)

 demo3

 

Esta semana, también ha visto la luz la siguiente versión de los componentes de Cadetill para trabajar con Google Maps. La librería GMLib; En este caso la versión 0.1.5a. Añaden bastantes correcciones y nuevas funcionalidades respecto a la anterior versión.

47_web20_320x240_gmlib 

“GMLib (Google Maps Library) son una serie de componentes para Delphi que encapsulan el API de Google Maps y así poder gestionar los mapas de Google de forma sencilla mostrando el resultado en un TWebBrowser.“

 

Siguiendo con el tema de FireMonkey, desde hace unos días podemos descargar desde la web de Embarcadero de una versión “free” de la herramienta de conversión entre VCL y FireMonkey llamada Mida. No he tenido tiempo de probarla, así que si alguien tiene oportunidad estaría bien que compartiera sus experiencias. Trabaja con componentes de terceros, además de los estándard, LiveBindings, Estilos y bastantes cosas más, aunque no todas disponibles en la versión gratuita.

Icarus_48También estos días se ha liberado la versión 3.4.4 de Icarus. Se trata de una utilidad gratuita de la casa Peganza (http://www.peganza.com) la misma que comercializa PAL (Pascal Analizer). Icarus es una “analizados de units”; Permite analizar el código de proyectos Delphi en busca de units no necesarias añadidas al uses o de aquellas que pueden ser movidas entre las secciones de Interface e Implementation.

Hoy mismo leo sobre la La versión 2.6 de las DDevExtensions se ha liberado estos días. Podéis descargarla para las diferentes versiones de los compiladores y leer sobre los cambios y correcciones de la última versión en este link (DDevExtensions 2.6). Gran trabajo que va mejorando versión a versión.

Poco a poco van apareciendo componentes nativos para FireMonkey. Es una tecnología nueva para los que trabajamos con las herramientas de Embarcadero y es normal que el arranque cueste un poco. Ya conocía un paquete de componentes específicos de la mano de TMS y estos días he leído que arcana también ha publicado Apesuite, una serie de componentes para FMX.
Siempre es una buena noticia que las empresas apuesten, se involucren y vaya generando componentes para FMX.

Por último os dejo esta completísima recopilación de reursos para FireMonkey. Si deseáis introduciros en este tema y empezar a hacer “pinitos» con esta tecnología debéis guardaros esta recopilación. Además de la propia documentación de Embarcadero, aquí podéis encontrar una amplia variedad de links que abarcan bastantes aspectos.

Introduction

Styles

What about the VCL?

Networking

IDE

Forms

File I/O

Video and sound

DataSnap

Controlling other programs

Printing

3D animation

Runtime packages and DLLs

Component development

Errors

Bugs

Third Party

 

    Un saludo y hasta la próxima.
Categories: Delphi, FireMonkey, Resumen Tags: ,

Yo ya tengo el mio…

miércoles, 14 de marzo de 2012 4 comentarios

Pues esta misma mañana (la verdad es que ha ido rápido) me ha llegado la última adquisición que he hecho. Y además venía con «regalito»…  ;-)

Como bien dicen, «una imagen vale más que mil palabras»

 

 

 

Podéis consultar todos los detalles desde la web de Danysoft.
Además allí está para descarga el índice del libro para ver con detalle todos los contenidos.

Un saludo a todos.

Categories: Delphi, FireMonkey Tags: , ,

Testeando XE2 (aplicación FireMonkey…)

miércoles, 9 de noviembre de 2011 9 comentarios

Hace unas semanas comencé a “trastear» con XE2, con FireMonkey, con los liveBindings, estilos y algunas características más…  Estuve posteando aquí las primeras impresiones y los resultados de esas  primeras pruebas.

En esas entradas he realizado un primer acercamiento a estas tecnologías, he dado un repaso y he testeado por encima algunas de sus características. La idea ahora, es ir un poco más allá.

He leído en algunos foros opiniones sobre que FireMonkey está «a medias» o «incompleto». Respeto esas opiniones, pero personalmente no estoy de acuerdo. Creo (y aquí es donde puede estar el error ) que se compara a FireMonkey con la VCL y las características que posee esta. Desde ese punto de vista sí puede parecer que  «le faltan cosas» y eso puede dar una sensación de que es una tecnología inacabada.

Pienso que el objetivo final de FireMokey no es, llegar a conseguir todas las características con las que cuenta la VCL. Es algo totalmente nuevo que avanza en una dirección paralela, algunas cosas tendrá sentido «adoptarlas» y otras no, pero a mi entender eso es «añadir» no «completar».

Hace tiempo publiqué en el blog un pequeño ejemplo de cómo cargar ficheros  GPX  (alternativa generando KML) procedentes de dispositivos GPS y visualizar esos tracks o rutas en una Aplicación  Delphi. Me he decidido por intentar realizar esta pequeña aplicación utilizando FireMonkey.


TActionList, ¿dónde está?

Lo primero que me he encontrado, aunque en realidad ya lo había visto en las primeras pruebas, es que no puedo utilizar un TActionList.  Este componente no está en la paleta donde debería estar o donde uno esperaría encontrarlo. Una cosa que sorprende es que los componentes estandard de FireMonkey sí poseen la propiedad Action para poder asignar un elemento. No es que sea imprescindible, pero es muy cómodo.

Lo siguiente que me planteo es la importación de datos desde un fichero GPX. En su día la hice utilizando el XMLmapper, pues los ficheros GPX son en realidad ficheros XML. Me propongo utilizar el mismo modelo utilizado anteriormente;  Importar el fichero GPX a un TClientDataset para getionarlo después de forma local.

TXMLTransformProvider, ¿dónde está?

Al igual que me ha pasado anteriormente, coloco un TClientDataset y cuando voy a colocar el TXMLTransformProvider no está donde esperaba encontrarlo.

He realizado un par de pruebas y lo más curioso es que creando y configurando el componente «a mano» funciona perfectamente. Con un código como este y configurando los campos apropiados en diseño el componente funciona perfectamente, importa los datos e incluso se pueden configurar LiveBindings para mostrar el resultado en un Grid.

  XMLTransform := TXMLTransformProvider.Create(nil);
  XMLTransform.TransformRead.TransformationFile :=
    'd:\Ficheros GPX\GPX_To_DP.xtr';
  XMLTransform.XMLDataFile :=
    'd:\Ficheros GPX\Ruta3.gpx';
  ClientDataSet1.SetProvider(XMLTransform);
  ClientDataSet1.Active := True;

Una vez activado el componente la importación se realiza sin problemas.

He dejado de lado esta cuestión por ahora; Tal vez más adelante me detenga para probar más cosas, pero para seguir adelante he realizado la importación de datos «manualmente», de forma que una vez conseguidos los datos en el TClientDataSet y puedo continuar a tratarlos.

El siguiente paso es colocar los elementos en el formulario, tal como van a ir distribuidos. Una cosa a la que hay que acostumbrarse es que los componentes de FireMonkey no poseen la propiedad

Anchors, que tan útil nos es utilizando componentes de la VCL. A cambio podemos ver que la propiedad Align posee una cantidad de valores superior que nos permite realizar más cosas. En este caso utilizamos la propiedad Align y la propiedad Padding para ir fijando los controles al formulario tal y como deseamos.

Se trata de conseguir lo mismo, pero por un camino diferente…

Una vez que los componentes básicos ya están colocados necesito plasmar en pantalla una serie de coordenadas. Para ello he escogido el componente TPath. La idea es que permite representar una serie de puntos que forman una línea o camino.
La potencia y la velocidad llaman la atención, pero también la sencillez.

 

Basta con soltar el componente en pantalla y utilizando la propiedad Data, colocar lo siguiente para conseguir una imagen (o path) como el que veis más abajo (se puede hacer en diseño utilizando un pequeño formulario de edición):

M 0,2 L 1,2 L 1,5 L 2,5 L 2,2 L 3,2 L 1.5 0 L 0,2

Si lo pensáis un poco, no son más que coordenadas precedidas por el tipo de «unión» o «elemento» que queremos utilizar entre ellas; la Primera M se refiere a MOVER, las L se refieren a LINEA.

Es así de sencillo y así de potente.

Un código como este, os podéis imaginar lo que dará como resultado:

for I := -360 to 360 do begin
    n := DegToRad(i);
    res := Sin(n);
    //res := Sin(n) * Sin(n);
    //res := Tan(n);
    if (Str = '') then begin
      Str := 'M ' + FloatToStrF(n, ffFixed, 35, 10) +
              ' ' + FloatToStrF(res, ffFixed, 35, 10);
    end
    else begin
      Str := Str + ',' + 'L ' + FloatToStrF(n, ffFixed, 35, 10) +
             ' ' + FloatToStrF(res, ffFixed, 35, 10);
    end;
  end;
  Path1.Data.Data := Str;

Con esto más o menos ya está todo completo. Los componente básicos ya están escogidos.

He utilizado LiveBindings para poder mostrar los datos en de las coordenadas en un TStringGrid; También he aplicado un estilo visual a la aplicación y por último una par de animaciones para dar más vistosidad a la visualización del track.

La conclusión que saco, es que  sí se pueden hacer aplicaciones con FireMonkey, lo que pasa que tal vez en algunos aspectos debamos pensar las cosas con otro enfoque o hacerlas de otra manera. Seguramente está en los planes de Embarcadero (eso espero) ampliar sus funcionalidades y el número de componentes.

Por último comentar que me he quedado con la ganas de poder compilar la aplicación y generarla para iOS, pero por ahora, no dispongo de los medios para hacerlo. Sobre todo me queda la duda de qué hubiera pasado con una aplicación, de un programador como yo con «visión de Windows», al compilarla en MAC.

¿Algun error? ¿Algun problema? ¿Warinigs? ¿Algun elemento que no puedo utilizar?  ¿?¿?¿?

Si alguien se anima a hacerlo, le agradecería que nos comunicara el resultado y me enviara alguna pantallita.   ;-)

Os dejo los enlaces al código fuente y al ejecutable (este último comprimido con UPX) junto con algunos ficheros GPX que podéis usar para las pruebas.

<Descargar el código fuente>

<Descargar binario – EXE>

[wpfilebase tag=file id=1 /]

[wpfilebase tag=file id=2 /]

NOTA: Acabo de corregir un par de errores en el código y añadida la DLL (midas.dll) porque quien no la tenga no podrá ejecutar la demo (gracias Rafa).

Como siempre los comentarios, sugerencias, críticas y demás son bienvenidos.

Un saludo y hasta la próxima.

Categories: Aplicación, Delphi, FireMonkey, XE2 Tags: ,

VCL y FireMonkey

martes, 4 de octubre de 2011 10 comentarios

imagen1

Está claro que FireMonkey (FM) es una tecnología súmamente atractiva y desde el mismo día que llegó (y vimos los primeros vídeos), la mayoría de nosotros está deseando poder integrarla en nuestras aplicaciones.

En el momento en que nos planteamos desarrollar aplicaciones nuevas, podemos tomar la decisión de escoger FireMonkey, si nuestras necesidades están cubiertas por esta librería (componentes y funcionalidad),  pero la pregunta que nos hacemos muchos de nosotros es:

¿Y qué hay con las aplicaciones que ya tenemos?

Está claro que no podemos “mezclar” en un proyecto formularios de la VCL y de FireMonkey. La ayuda nos dice lo siguiente (docwiki):

______________________________________________________________________
Caution:
FireMonkey (FMX) and the Visual Component Library (VCL) are not compatible and cannot be used in the same project or application. That is, an application must be exclusively one or the other, either FireMonkey or VCL. The incompatibility is caused by framework differences between FireMonkey (FMX) and VCL.
______________________________________________________________________

¿O si? (bueno luego hablaremos de esto…)

Sólo basta con intentarlo en el IDE; Creamos un proyecto/aplicación VCL e intentamos añadir un formulario «tipo FireMonkey»; Instantáneamente obtendremos un mensaje como este:

Imagen907

El mensaje es claro. No podemos añadir a un “proyecto VCL” un formulario FireMonkey.   ;-(
Bueno, no desesperemos; Delphi es mucho Delphi y ofrece “otras” posibilidades… (Packages)

Me he planteado este problema, mi cabeza ha empezado a dar vueltas y he comenzado a “trastear”…  ;-D

NOTA: Estoy pensando en aplicaciones que tenemos funcionando en Windows y que queremos que sigan así (descartando características de Multiplatarforma –al menos a priori-).

NOTA2: Como en las últimas entradas, he cogido Delphi XE2 y he empezado desde cero.

PRIMERA CUESTIÓN

Crear un package con un formulario FireMonkey.

Pues me he puesto manos a la obra…
He abierto un nuevo package y he añadido un formulario de FireMonkey; Un par de controles, un Timer y una vez compilado, se ha generado el package correspondiente (sin aparentes problemas).

Imagen908

Como veis a la izquierda la estructura del formulario es sencilla y es lo único que posee el package.

SEGUNDA CUESTIÓN:

¿Podré cargar este package desde una aplicación Delphi (VCL)?

Bueno, si el package se ha generado sin problemas, cargarlo de forma dinámica desde una aplicación no tendría porque fallar.

Creo un proyecto VCL estándar y utilizo el procedimiento LoadLibrary para cargar una BPL de disco; La BPL en la que he añadido el formulario FireMonkey. El código de la carga es el mismo que para cualquier otro package.

 

var
  H: Thandle;
  fName:String;
begin
  // Nombre del package
  fName := Edit1.Text;
  // existe el fichero?
  if not FileExists(fName) then begin
    Memo1.Lines.Add('Error al cargar el package; Fichero inexistente: ' +
      fName);
    Exit;
  end;
 
  Memo1.Lines.Add('Se va a cargar el package...');
  // Cargando
  H := LoadPackage(Edit1.Text);
  // Cargado correctamente?
  if (H &gt; 0) then begin
    Memo1.Lines.Add('El package se ha cargado correctamente (' +
       IntToStr(h) + ')');
  end
  else begin
    Memo1.Lines.Add('Error, no se ha cargado el packae');
  end;

 

En este caso el nombre del package lo “pasamos” utilizando un componente de edición. Además he añadido al packages un par de procedimientos de INITIALIZATION y FINALIZATION; El de inicialización se encarga de crear una instancia del formulario y mostrarla por pantalla, mientras que el de finalización lo libera. El código que añadiríamos al final del .PAS sería este:

procedure Start_Pack();
begin
  // Crear el formulario
  FormMainFM := TFormMainFM.Create(nil);
  FormMainFM.ShowModal;
end;
 
procedure Finish_Pack();
begin
  // Liberar el form
  FormMainFM.Free;
end;
 
//=========================================================================
// I N I T I A L I Z A T I O N
//=========================================================================
initialization
  Start_Pack();
  RegisterClass(TFormMainFM);
 
//=========================================================================
// F I N A L I Z A T I O N
//=========================================================================
finalization
  Finish_Pack();
  UnregisterClass(TFormMainFM);

Si ejecutamos el programa podemos ver que el Package se carga correctamente y que en ese momento se ejecuta el procedimiento de inicialización, con lo que se crea el formulario (FMX). He añadido estilos a ambos formularios para que se aprecie la diferencia; Al formulario de la VCL con los Visual Styles y al de FireMonkey con el componente TStyleBook. El resultado es el que véis aquí:

Imagen909

Llegados a este punto. Pues he de decir que yo personalmente me he llevado una sorpresa. Ya se lo que dice la ayuda (lo he vuelto a leer), pero la aplicación se ha ejecutado y aunque es sencilla, aparentemente no parece tener problemas (he realizado la prueba en XP, en Windows Server y en Windows 7) .

Resumiendo… Lo que he hecho hasta ahora es generar un proyecto en Delphi (VCL) compilarlo sin runtime packages y cargar una BPL de forma dinámica (como si fuera una DLL) que a su vez muestra un formulario “FireMonkey” cuando se Inicializa. No está mal, aunque podemos ir un poco más allá.

¿Me pregunto qué pasará cuando intente acceder por RTTI a la información del package?

TERCERA CUESTIÓN:

Acceder por RTTI desde una aplicación “VCL” a los métodos de un form “FireMonkey” almacenado en una BPL.

Para ello lo primero que debemos hacer algunos cambios:

  1. Nuestra aplicación  VCL, ahora debe compilar con “runtime packages” para poder compartir la información RTTI con los packages dinámicos.
  2. En nuestro package que contiene el formulario “FireMonkey” vamos a Registrar la clase del formulario, para poder acceder a ella posteriormente con GetClass. Para ello utilizaremos los procedimientos de Inicialización y Finalización vistos anteriormente.
    //=========================================================================
    // I N I T I A L I Z A T I O N
    //=========================================================================
    initialization
      //-- Start_Pack();  // Lo crearemos “manualmente”
      RegisterClass(TFormMainFM);
     
    //=========================================================================
    // F I N A L I Z A T I O N
    //=========================================================================
    finalization
      //-- Finish_Pack();
      UnregisterClass(TFormMainFM);
  3. A nuestro formulario vamos a añadir en la parte published, varios métodos de clase (aunque esto último no es necesario) a los que accederemos vía RTTI. Un Timer y un par de procedimientos para controlar una animación. Además de un procedimiento que creará el formulario (ExecForm).
  4. Por último vamos a eliminar la creación del formulario en la carga del package, para hacerlo nosotros vía RTTI. Si os fijáis en el código superior, he comentado los procedimientos Start_Pack y Finish_Packque se encargaban de la creación y destrucción.
      // en la parte published del formualrio
      published
        // Método de clase para crear y visualizar
        class procedure ExecForm();
        class procedure Start();
        class procedure Stop();

     

      // Y la implementación (asumimos que el formulario ya estará creado)
      //...// Actiar el Timer para iniciar la animación
    class procedure TFormMainFM.Start;
    begin
      FormMainFM.TimerRot.Enabled := True;
    end;
     
    // Para el Timer y detener la animación
    class procedure TFormMainFM.Stop;
    begin
      FormMainFM.TimerRot.Enabled := False;
    end;
     
    // Crear el formulario y visualizarlo
    class procedure TFormMainFM.ExecForm();
    begin 
      FormMainFM := TFormMainFM.Create(nil); 
      FormMainFM.Show;
    end;

Hecho esto, nuestro método de carga ahora es un poco más complejo. Una vez cargado el package de forma dinámica, busco mediante RTTI la clase del formulario e intento crearlo. El código es el siguiente:

var
  H: Thandle;
  res:integer;
  fName:string;
  AClass:TPersistentClass;
begin
 
  fName := Edit1.Text;
 
  // existe el fichero?
  if not FileExists(fName) then begin
    Memo1.Lines.Add('Error al cargar el package; Fichero inexistente: ' +
       fName);
    Exit;
  end;
 
  Memo1.Lines.Add('El fichero de package existe en disco');
  Memo1.Lines.Add('Se va a cargar el package...');
 
  // Cargando
  H := LoadPackage(Edit1.Text);
 
  // Cargado correctamente?
  if (H &gt; 0) then begin
    Memo1.Lines.Add('El package se ha cargado correctamente (' +
         IntToStr(h) + ')');
 
    // Acceder a la clase del form
    AClass := GetClass('TFormMainFM');
    // encontrada
    if Assigned(AClass) then begin
      Memo1.Lines.Add('AClass&lt;&gt;nil; Encontrada la referencia' +
          ' al formulario');
      // Crear el form
      F := TFormClass(AClass).Create(nil);
      Memo1.Lines.Add('Creado el form correctamente; Accediendo ' +
        ' a los métodos');
      // Acceder al método
      Routine.Data := Pointer(F);
      // Ejecutar al código
      Routine.Code := (F).MethodAddress('ExecForm');
 
      // No ha encontrado el código de la rutina...
      if (Routine.Code &lt;&gt; nil) then begin
        Memo1.Lines.Add('Se ha encontrado el punto de entrada del método ');
        Memo1.Lines.Add('Se va a ejecutar el método...');
        // Ejecutarlo
        TExecuteExecForm(Routine);
        Memo1.Lines.Add('Ejecutado OK. Form visible');
 
        btnStart.Visible := True;
        btnStop.Visible := True;
        Button1.Enabled := False;
      end
      else  begin
        Memo1.Lines.Add('No se ha encontrado el punto de entrada del método ');
      end;
    end
    else begin
      Memo1.Lines.Add('Error, no se ha encontrado la referencia a la ' +
        'clase en el package ' + fName);
    end;
  end
  else begin
    Memo1.Lines.Add('Error, no se ha cargado el package');
  end;
end;

 

He utilizado un Memo en el formulario principal para ir mostrando los diferentes mensajes (los pasos que se van realizando). Una vez que ejecutamos el código, podemos ver que la salida de LOG es la esperada y el formulario se visualiza correctamente.

 

Imagen910

 

De la misma manera, si ejecutamos los métodos Start y Stop (vía RTTI) funcionan de forma correcta.

CONCLUSIÓN:

La primera conclusión que extraigo de todo esto (contando que las pruebas que he realizado son bastante sencillas), es que utilizando packages (creo que es la mejor forma), tenemos la posibilidad de utilizar FireMonkey en una aplicación «VCL». Está claro que esto invalida la posibilidad de utilizar la «multiplataforma» con esa aplicación, pero tal y como os he comentado, no era ese el objetivo de estas pruebas.

¿Para qué puede servir esto?

Se me ocurren a priori 2 situaciones donde esto podría ser «utilizable».

La primera es que tengamos aplicaciones antiguas desarrolladas en Delphi y a las que queramos «añadir» alguna característica donde FireMonkey pueda aplicar su potencial. Por ejemplo, un módulo donde tengamos que realizar animaciones o visualizaciones 3D; Incluso sacar partido de la facilidad que FireMonkey tiene para trabajar con modelos importador de herramientas de modelado (3DS).

La segunda, es la de poder «migrar» de forma paulatina aplicaciones que tengamos funcionando; Si cumplen unos determinados requisitos, puede ser que la migración se pueda hacer de forma escalonada. En este caso ya deberían trabajar con packages y facilitaría mucho si la lógica de negocio la tenemos «independiente» a la parte de Interficie.

Todo esto con la RESERVA de ver qué otras implicaciones más profundas puede tener este diseño. El hecho de que Embarcadero diga que es incompatible utilizarlos en el mismo proyecto, debe ser por algo, aunque en este momento no se porqué.  ¿?¿?¿?

 

BONUS TRACK:

Por último se me ha ocurrido hacer una prueba más. Probar, por probar,…    ;-)

Crear un proyecto «VCL», y añadir directamente un formulario FMX al proyecto. Aunque en IDE avisa con un Warninig, deja hacerlo.
Compilas, ejecutas y ¡Voilà! ¡Sorpresa!

Se ejecuta perfectamente.

En este punto he buscado por Internet si a alguien más se le ha ocurrido hacer esto mismo y he encontrado algunas referencias. La más interesante en StackOverFlow (y con esto completo la entrada) es que apenas con 3 líneas, podemos conseguir, no sólo abrir un formulario FireMonkey como os he mostrado, sino «incrustarlo» dentro de uno «VCL».

procedure TForm3.Button1Click(Sender: TObject);
begin
  FormMainFM := TFormMainFM.Create(nil);
  FormMainFM.Show;
  Panel1.Form := FormMainFM;
  FormMainFM.Start;
end;

 

     

Aquí os enseño las imágenes en diseño y en ejecución.

Vuelvo a decir, que todo esto no creo que se pueda tomar como base para diseño de aplicaciones, entre otras cosas porque las pruebas son bastantes  «simples» y porque desde Embarcadero lo desaconsejan, pero se puede tener en cuenta como alternativa puntual.

Os adjunto los enlaces a los proyectos con código y a los ejecutable compilados por si queréis verlos funcionando. Los segundos están comprimidos con UPX para reducir su tamaño.

Aunque ya he comentado el enlace, os animo a revisar la entrada en Stackoverflow, » Delphi XE2: Possible to instantiate a FireMonkey Form in VCL application?»

Os añado también un enlace al blog de RemObjects, donde aparece una referenca a esta cuestión; «Hydra and FireMonkey – Best Friends Forever».

Como siempre, comentarios, quejas, críticas, sugerencias,…  serán bienvenidas.

Un saludo.

Categories: FireMonkey, OOP, XE2 Tags: , ,

Testeando XE2… (FireMonkey)

martes, 13 de septiembre de 2011 11 comentarios

Pues ya tengo Delphi XE2 en marcha. Que ya lo tengo instalado ¡Vamos!

No se a vosotros, pero a mi me pasa (y no sólo con esta versión) que una vez que la tengo instalada, lo primero que se me ocurre es probarla. Probar las nuevas características y ver qué tal funcionan.

¡¡Eso es lo que hace todo el mundo!! Diréis.

Bueno, sí y no. Me refiero a «probarlas en frío». Sin saber nada más. Sin leer nada más.
Se trata de abrir un proyecto en blanco y empezar a probar cosas. Cosas totalmente nuevas. Cosas que no existían hasta ahora. Cosas de las que he oído hablar, pero no he leído nada.

Eso me da una idea de cómo son de fáciles a la hora de asimilar. Difíciles, complicadas, rebuscadas,… Busco documentación y veo cómo se llega a ella, si la hay, cómo es de clara,…

Todo el mundo habla estos días de FireMonkey.  ;-D    ¡¡Pues allá que voy yo!!

He ido al menú de fichero y he creado una nueva aplicación de este tipo (Fire Monkey HD Application).

A priori todo parece normal; el formulario se ve algo diferente, pero todo lo demás tiene «la misma pinta».

Pongo algunos componentes, unos botones, un checkbox, una statusBar y una imagen. Mi primera sorpresa viene cuando voy a buscar la propiedad Caption del botón y no está.   8-|

¡No puede ser! Vuelvo a buscar y efectívamente no está.

En su lugar veo la propiedad Text. Pruebo y efectívamente pertenece al caption del TButton.

No parece que tenga mayor importancia…

Pongo un checkbox y al ir a buscar la propiedad Checked…  ¿??¿?¿   ¡¡No está!!    8-||

Vuelvo a revisar las propiedades y…  encuentro una propiedad IsChecked que pertenece a lo que normalmente se hace con la propiedad Checked.

Dejando de lado esto (cuestión de la adaptación de los nuevos componentes adquiridos por Embarcadero-me imagino-) el resto de cosas que he probado son bastante intuitivas y algunas bastante impresionantes. Aplicar un efecto (para lo que antes necesitábamos bastante código o componentes especializados) o realizar una rotación de una imagen es algo «trivial» (por su sencillez).

La velocidad es muy buena y la primera impresión muy positiva.

Os dejo este primer ejemplo; Bastante «tonto» por su funcionalidad, pero también por la complejidad que me ha conllevado (bastante poca).

Aquí los fuentes y el ejecutable, aunque sinceramente no creo que tengan mucho interés, desde en punto de vista de la codificación.

NOTA: Sigo buscando cómo asignarle un texto a la StatusBar que he puesto en el formulario…    ;-D

Un saludo.