Archivo de la categoría: Xailer 7

Nuevos controles visuales en Xailer 7

En los próximos artículos vamos a repasar todos los nuevos controles que incluye el futuro Xailer 7. Existen nuevos controles que son simplemente versiones más vistosas de controles ya existentes, pero adaptados al estilo de Windows. Motivo por el cual todos estos nuevos controles se califican como ‘modernos’ y tiene una pestaña propia en el propio IDE. Sería el caso de los controles:

  • TButtonMod: Botón
  • TEditMod: Edit (Ya existente en Xailer 6, pero se ha adaptado para su funcionamiento en modo oscuro)
  • TMemoMod: Memo (Ya existente en Xailer 6, pero se ha adaptado para su funcionamiento en modo oscuro)
  • TCheckBoxMod: Checkbox o casilla de verificación
  • TRadioMod: Botón tipo Radio
  • TProgressBarMod: Barra de progreso
  • TTrackBarMod: Barra de seguimiento
  • TSwitch: Interruptor (Ya existente en Xailer 6, pero se ha adaptado para su funcionamiento en modo oscuro)
  • TGroupBoxMod: Cuadro de grupo
  • TDateEditMod: Edit especializado en la edición de fechas, utilizando el nuevo control de TCalendarMod
  • THeaderMod: Control para manejar cabeceras de browses o barras de botones

Además de estos controles se han incorporado algunos nuevos que o son completamente nuevos o por su gran mejora, merece la pena dedicarles un artículo a cada uno de ellos, como son:

  • TWebView: Control tipo browser basado en Microsoft Edge con integración total con sus aplicaciones.
  • TListBoxMod: Control tipo listbox con todo lo que pueda necesitar
  • TComboBoxMod: Control tipo ComboBox
  • TBtnPanelMod: Panel contenedor con efecto botón
  • TProgressCircle: Barra de progreso circular
  • TCalendarMod: Control tipo calendario
  • TTreeViewMod: Control tipo Treeview muy potente y completamente configurable
  • TCircularImage: Control tipo imagen con enmarcado circular
  • TBrowseMod: Control tipo browse que mejora sustancialmente el actual browse.

Todos estos nuevos controles que son susceptibles de tener su equivalente como DataControl, también han sido creados para el nuevo Xailer 7. Por lo tanto y como pueden imaginar, Xailer 7 es sin duda el mayor esfuerzo que se ha realizado en una actualización de Xailer desde Xailer 2.

Otra característica fundamental de los nuevos controles es que admiten el uso de etiquetas básicas tipo HTML en las propiedades de tipo cadena, como por ejemplo la propiedad cText del TButtonMod.

Comenzamos con el control TBtnPanelMod. Este nuevo control de Xailer 7 ofrece una gran funcionalidad que consiste en poder establecer que un contenedor de controles se comporte como un botón en su conjunto.

Esto nos permite crear botones con una mayor funcionalidad que la que teníamos hasta ahora. Seguro que ya habrá descubierto que son ampliamente utilizados en Windows 10.

Espero que les guste. Pronto más controles. Estén atentos. Gracias.

Visor e impresor de archivos PDF en Xailer 7

Xailer 7 incorpora controles para visualizar e imprimir cualquier archivo PDF de una forma muy sencilla, sin limitaciones, con una increíble velocidad y sin que nuestra aplicación vaya a crecer demasiado por ello. Para conseguirlo Xailer 7 se apoya en la utilidad Sumatra PDF.

Sumatra PDF reader es una estupenda herramienta para visualizar e imprimir archivos PDF. Es muy rápida, liviana y su integración con Xailer es total, ya que se comporta como un control más dentro de su aplicación, que puede fácilmente seleccionar desde la propia paleta de controles del IDE.

Para poder utilizar el control es necesario que su aplicación pueda acceder a un único fichero de nombre SUMATRAPDF.EXE. Con Xailer 7 ofrecemos dos versiones de dicho ejecutable. La versión 3.1 por tener un tamaño ridículo de 2.721 Kb que es posible que sea suficiente para los archivos que usted desea mostrar. Y la la versión 3.2 que tiene un tamaño de 14.017 Kb que tampoco es muy grande teniendo en cuenta todo lo que hace.

Sumatra PDF viewer soporta los siguientes tipos de archivos: PDF, EPUB, MOBI, CHM, XPS, DjVu, CBZ y CBR. Y las siguientes extensiones:

  • PDF (.pdf), unencrypted EPUB (.epub), MOBI (.mobi)
  • Fiction Wise (.fb2, .fb2z, .zfb2), Palm DOC format (.pdb)
  • comic book files: (.cbz, .cbr, .cbt, .cb7z)
  • DjVu (.djv, .djvu), Microsoft Compiled HTML Html (.chm)
  • XPS (.xps), images (.jpg, .png,.gif, .webp, .tiff, tga, .j2k)

Puede obtener más información sobre Sumatra en esta dirección: https://www.sumatrapdfreader.org

La licencia con la que se ofrece este producto es: GNU General Public License v3, que en principio es compatible con el uso comercial del producto siempre que sigan todas las restricciones que impone la licencia. No obstante, el equipo de Xailer se puso en contacto con el desarrollador Krzysztof Kowalczyk para confirmarlo. Puede seguir la pregunta y respuesta en el siguiente enlace en su foro.

Mejoras en los Data Controls de Xailer 7

Os sigo comentando las mejoras importantes que incluirá el futuro Xailer 7. Como muchos sabéis, cuando se utilizan DataControls, Xailer es capaz de acceder a los distintas campos de una tabla o cursor como si se trataran de miembros de la propia clase TDataset. Un ejemplo:

WITH OBJECT oDataset
  :Edit()
  :Codigo := 1 // campo
  :Nombre := "Ignacio" // campo
  :Update()
END WITH

Cuando el nombre del campo coincide con un miembro real del propio dataset, el acceso al campo no es posible, ya que tiene preferencia el miembro de la clase TDataset. Para resolver este problema, hasta ahora se podía utilizar el método TDataset:FieldPut() directamente o bien recuperar el objeto TDataField con el método oFieldByName() y luego asignarle el valor.

A partir de Xailer 7 tenemos una solución más elegante para acceder a cualquier campo del TDataset aunque coincida su nombre con algún miembro de la clase y consiste en utilizar la siguiente instrucción: TDataset:!Campo

Observe como la única diferencia existente es la admiración después de ‘:’. Además, de esta forma, usted mismo como programador, sabrá si está accediendo a un campo o a un miembro de la clase, lo que hará que su código sea mucho más legible.

Otra mejora importante: En Xailer 7 hemos hecho un pequeño guiño a las bases de datos NoSQL. En las bases de datos NOSQL los esquemas de datos son dinámicos, es decir, no existe una estructura fija de tabla y la consistencia de los datos es menos importante. En Xailer 7 hemos querido incluir alguna de sus cualidades y ahora cualquier dataset, incluso una tabla DBF puede tener la habilidad de guardar en su tabla cualquier campo, aunque éste no exista ni siquiera en la tabla. Sólo es necesario la existencia de un campo en la base de datos de nombre MoreData, que lógicamente deberá de ser tipo BLOB o MEMO.

Para acceder o establecer el valor de éste campo virtual tan sólo que hay que usar la sintaxis: oDataset:!Campo. Es decir, hay que incluir el carácter ‘!’ del que hemos hablado anteriormente. ¡Eso es todo! Internamente toda la información se guarda con formato JSON dentro de ese campo y por lo tanto se pueden realizar búsquedas en el campo ‘MoreData’ e incluso editarlo desde su editor de bases de datos preferido. Nuestro editor de tablas SQLite ya soporte el tipo de campo JSON, por lo que en dicho caso, lo preferible es definir el campo con ese tipo.

Las posibilidades de este nuevo sistema son múltiples. A modo de ejemplo:

  • Guardar en una tabla de clientes las direcciones completas de todas sus delegaciones (no es necesario crear una tabla clientes-delegaciones)
  • Guardar en una tabla de artículos una relación completa de todas las ofertas que tiene por periodo o cantidad
  • Evitar tener que modificar una tabla por la necesidad de incluir un nuevo campo

Una de las grandes ventajas de este nuevo sistema, es que puede guardar en la tabla cualquier tipo de dato, incluso matrices y objetos Hash.

No obstante, existen limitaciones, que son insalvables, como son:

  • Los campos virtuales no pueden ser asignados a la propiedad ‘oField‘ de un datacontrol
  • No se pueden realizar búsquedas directas sobre campos virtuales. Deberá buscar internamente en el campo ‘MoreData’

Animaciones en Xailer 7

Las animaciones son clases que permiten establecer distintos tipos de animaciones en cualquier control visual. Su funcionamiento se basa en utilizar Futuros para de esta forma no provocar la congelación de la aplicación durante todo el tiempo que dure la animación. Para más información acerca de los futuros, consulte el artículo donde se trata.

Demo de animaciones en el canal de Xailer en YouTube

La clase base de todas las animaciones es TAnimation la cual ofrece toda funcionalidad necesaria para realizar cualquier tipo de animación. Existen dos clases que heredan de TAnimation que están especializadas en realizar la animación de una forma muy sencilla:

TAniNumProperty: Esta clase permite establecer la animación en base a una de las propiedades del control.

En este ejemplo puede entender perfectamente su comportamiento. El objeto TAniNumProperty controla la propiedad ‘nWidth‘ del control ‘oEdit1‘ y va modificar dicha propiedad desde su valor actual (lStartFromCurrent a verdadero) hasta un valor de 300 (nStopValue) y lo hará en un periodo de 1 segundo (nDuration). Todo el proceso comenzará en cuanto la propiedad lEnabled se encuentre a verdadero o ejecute su método Start(). Es así de fácil establecer una animación en cualquier control.

TAniControlSize: Esta clase permite establecer la animación en base a las dimensiones del control. Es decir, de su tamaño marcado por sus propiedades: nLeft, nTop, nWidth y nHeight. Su uso se restringe básicamente a modificar el tamaño de cualquier control desde una posición y tamaño inicial a una posición y tamaño final.

En este ejemplo puede entender perfectamente su comportamiento. El objeto TAniControlSize controla las dimensiones del control ‘oMemo1‘ y va modificar dichas dimensiones desde su valor actual (lStartFromCurrent a verdadero) hasta un valor de {96,48,300,200} (aStopValues) y lo hará en un periodo de 1 segundo (nDuration). Todo el proceso comenzará en cuanto la propiedad lEnabled se encuentre a verdadero o ejecute su método Start().

Ambas clases tienen además una serie de propiedades muy interesantes, que son:

  • nInterpolation: Esta propiedad permite establecer el tipo de animación. La forma más básica sería una interpolación lineal (aiLINEAR) que es la única existente en Xailer Personal y Xailer Professional. Xailer Enterprise dispone de muchos más tipos: rebote, explosión, elástica y circular.
  • nDelay: Permite establecer una demora en milisegundos en el inicio de la animación. Esta propiedad es muy útil cuando se pone la propiedad lEnabled a verdadero en el propio IDE y por lo tanto es necesario que se cargue y muestre el formulario antes de que se procese la animación.
  • lLoop: Si esta propiedad está a verdadero la animación comenzará de nuevo automáticamente cuando termine. Y por lo tanto la animación seguirá hasta que lEnabled pase a ser falso.
  • lReverse: Si esta propiedad está a verdadero se intercambian los valores de ‘Start‘ y ‘Stop
  • lAutoReverse: Esta propiedad permite que se haga una reversión automática cuando termine un ciclo, de tal forma que en el siguiente ciclo se convierte el efecto contrario. Esta propiedad conjuntada con la propiedad lLoop a verdadero provoca el clásico efecto de zoom in- zoom out.
  • nSyncsInSec: Esta propiedad permite establecer el número de sincronizaciones que se harán del control por segundo. Cuanto mayor sea este número, en principio, más suave y fluido se verá el movimiento, pero no es así. Dependerá de la velocidad de su PC y el trabajo que tenga que hacer la animación, ya que puede ser que arrastre a otros controles que también estén visibles.

Espero que estas animaciones sean de su agrado. Estarán disponibles en Xailer 7.

Futuros y/o promesas en Xailer 7

Sin duda, los futuros o promesas son la funcionalidad más importante que incorporamos en el futuro Xailer 7 e incluso al propio lenguaje de programación Harbour. Los futuros o promesas son ampliamente conocidos por programadores de otros lenguajes más modernos y para aquellos que aún no los conozcáis, creo que la mejor introducción para ellos es decir que son la simplificación completa de la programación multi-hilo.

Según la Wikipedia, un valor futuro (también llamado un futuro o una promesa) es «Un reemplazo para un resultado que todavía no está disponible, generalmente debido a que su cómputo todavía no ha terminado, o su transferencia por la red no se ha completado.» Puede parecer una definición un poco críptica, pero indica claramente su funcionalidad aunque no hace mención a cómo funcionan ni en que se basan. La funcionalidad de los futuros o promesas está totalmente ligada a la programación multi-hilo. La programación multi-hilo puede llegar a ser tremendamente compleja debido a la facilidad existente de cometer errores de programación que colapsen nuestras aplicaciones o las hagan actuar de forma inesperada.

Un futuro o promesa está estrechamente ligado con el concepto de asíncrono. Es decir, un código que sabemos cuándo lo ejecutamos, pero que no sabemos cuando retornará con un resultado. Pensemos un una función estándar; ésta siempre devuelve un resultado cuando se termina de ejecutar el código que tiene en su interior. Si dicha función tiene que acceder a Internet o realizar un trabajo pesado, nuestra aplicación se quedará completamente paralizada hasta que dicho código termine. Para evitar este problema, en clásica programación multi-hilo crearíamos un proceso asíncrono a través de un hilo:

TThread():Run( bCode )

Donde bCode, es por ejemplo, un bloque de código que se ejecutará cuando se inicie el hilo. Independientemente del tiempo de proceso que necesite dicho código, el retorno desde la ejecución de esa línea será inmediato. Por lo tanto, será responsabilidad suya el crear mecanismos para saber cuando ese código ha terminado y si lo ha hecho correctamente o no. El asunto se complica cuando desde dicho código que se ejecuta en un segundo hilo queremos acceder a zonas de memoria que no han sido creadas en ese mismo hilo o incluso se pretende acceder a la pantalla en el más amplio sentido. La primera regla de oro a tener en cuenta es que desde un hilo secundario nunca se debe acceder a la pantalla y esto es así para cualquier entorno de desarrollo. No es una limitación de Xailer, Harbour o Windows. Aunque le parezca que funciona, olvídese, es un auténtico espejismo, su aplicación terminará con un GPF esporádico más pronto que tarde. La segunda regla de oro es evitar acceder a áreas de memoria creadas por el hilo principal u otros hilos y si se hace, establecer los mecanismos necesarios para que todos los hilos involucrados puedan acceder a esas mismas zonas de memoria de forma ordenada y sin bloquearse. En definitiva, demasiadas complicaciones que impiden que la programación multi-hilo sea ampliamente utilizada.

Los futuros o promesas nos simplifican tremendamente estos inconvenientes ya que tienen mecanismos para solucionar esos dos problemas, que son:

  • Control de cuando el proceso en un segundo hilo ha terminado, bien con éxito o con error a través un simple evento que se dispara cuando esto se produce.
  • Posibilidad de encadenar procesos asíncronos que se ejecutan en cascada.
  • Posibilidad de ejecutar código en el hilo principal desde el propio futuro, lo que permite, por ejemplo, operar con los controles que se ven en pantalla.

Xailer 7 incorpora varias formas de implementar los futuros:

  • A través de una cláusula ASYNC en la definición de función o método
  • Vía estricta programación orientada a objetos

A través de cláusula ASYNC:

Sólo tiene que añadir la cláusula ASYNC en la definición de método o función. Algo así:

METHOD Btn1Click( oSender ) CLASS TForm1 ASYNC

El código que se ejecutará en el futuro debe de ir incluido en comandos AWAIT:

AWAIT INLINE {||
FOR nFor := 1 TO 100
Sleep(10)
RETURN "Exit from first task"

NEXT
}

Puede haber más de una sentencia AWAIT en una misma función o método. Cuando termine la primera sentencia AWAIT de forma asíncrona, se procederá con la ejecución del código del siguiente AWAIT. Esto le permite encadenar procesos asíncronos de una forma tremendamente sencilla.

FUNCTION MyTest(...) ASYNC
AWAIT INLINE {||....}
AWAIT INLINE {||....}
AWAIT INLINE {||....}

Observe que es posible que cada sentencia AWAIT devuelva un valor y además también es posible saber si el AWAIT terminado ha sido con éxito o no. La variable privada de nombre LastAwait recoge la tarea (TFutureTask) que se acaba de terminar de procesar. Y por lo tanto desde la siguiente cláusula AWAIT puede comprobar si la tarea terminó con éxito y el valor retornado:

LastAwait:nState (uncompleted, completed with value, completed with error)
LastAwait:ReturnValue

AWAIT admite la definición del código como un bloque de código extendido utilizando la expresión AWAIT INLINE. Pero también puede llamar directamente a una función con la siguiente sintaxis:

AWAIT FUNCTION MiFuncion( … )

Para controlar como y cuando ha terminado el proceso asíncrono puede crear un AWAIT INLINE adicional sólo para controlarlo o simplemente utilizar el evento TFuture:OnComplete. Si es un poco observador se habrá dado cuenta de que aparentemente no existe ninguna variable que haga referencia a ese objeto TFuture que se menciona. Xailer crea esa variable por usted con ámbito local cuando utiliza la cláusula ASYNC con el nombre ThisFuture. De hecho Xailer crea un objeto TFuture de forma automática en cada función o método con la cláusula ASYNC y lo asigna a dicha variable. Por lo tanto, controlar el fin del proceso asíncrono sería tan sencillo como hacer algo así:

ThisFuture:OnComplete := {|| Msginfo( LastAwait:ReturnValue ) }

Ya hemos visto como crear y ejecutar procesos asíncronos, que incluso se ejecuten con varias tareas en cascada, pero aún no hemos visto nada de como ejecutar código en el hilo principal desde la tarea asíncrona, como por ejemplo cualquier operación de pantalla, que ya hemos indicado que no se pueden hacer desde tareas asíncronas. Para ello Xailer ofrece otro comando de uso muy sencillo y de parecida sintaxis al comando AWAIT, que es el comando SYNCHRO. Este comando se debe de utilizar únicamente desde bloques AWAIT INLINE o desde funciones AWAIT FUNCTION. Por ejemplo:

AWAIT INLINE {||
FOR nFor := 1 TO 100
Sleep(10)

SYNCHRO INLINE {|| ::oProgressBar:nValue := nFor }
RETURN "Exit from first task"

NEXT
}

Observe como actualizamos una barra de progreso desde la propia tarea asíncrona. Más fácil imposible. Al igual que el comando AWAIT que puede utilizar una función con AWAIT FUNCTION, el comando SYNCHRO también admite la sintaxis SYNCHRO FUNCTION en la cual puedo desarrollar toda la complejidad que pudiera tener el código.

A través de programación orientada a objetos:

Este es el método recomendado si tiene experiencia con Xailer o la programación orientada a objetos que ofrece Harbour. Observará que básicamente es lo mismo que hemos explicado hasta ahora, pero sin tener que usar un sólo comando. El primer paso es crear un objeto de la clase TFuture (operación que realiza internamente la cláusula ASYNC):

LOCAL oFuture AS CLASS TFuture
oFuture := TFuture():New()

A continuación hay que añadir las tareas para dicho futuro. Y lo haremos con el método AddThreadTask( bCode ) que recibe como parámetro un bloque de código a ejecutar en dicha tarea:

LOCAL oTask AS CLASS TFutureTask
LOCAL bWork

bWork := { ||
FOR nFor := 1 TO 100
Sleep(30)
NEXT
RETURN "Exit from first task"
}

oTask := oFuture:AddThreadTask( bWork )

Para poder ejecutar código en el hilo principal desde la tarea asíncrona, utilizaremos el método RunSynchroTask( bCode ) y lógicamente las llamadas a este método deben de realizarse desde la propia tarea:

LOCAL oFuture AS CLASS TFuture
LOCAL oTask AS CLASS TFutureTask
LOCAL bWork

bWork := { ||
FOR nFor := 1 TO 100
Sleep(30)

oFuture:RunSynchroTask( {||::oProgressBar:nValue := nFor } )
NEXT
RETURN "Exit from first task"
}

oTask := oFuture:AddThreadTask( bWork )

Por último, para controlar el resultado final del proceso:

oFuture:OnComplete := {|| .... }

Una puntualización importante a realizar es el hecho de que los procesos asíncronos se disparan inmediatamente cuando se crea la tarea. Es decir, AWAIT INLINE y su equivalente en POO TFuture:AddThreadTask( bCode ) no esperan. Ellos son los responsables de lanzar el hilo de ejecución secundario. Si existen varios AWAIT INLINE, cuando se ejecutan, se añaden a la lista de tareas a procesar por el Futuro. Si no hay ninguna tarea pendiente, el primer AWAIT INLINE se procesará de inmediato. Cuando éste termine, se ejecutará el siguiente.

Todo se puede complicar un poquito más, pero no mucho 😉 Es probable que en una tarea se produzca un error de ejecución. ¿Es posible controlarlo? ¡Lo es! y de una forma muy sencilla. El objeto ThisFuture tiene un evento de nombre OnError que recibe como parámetros el objeto TError y la TFutureTask. Si desde dicho evento retornamos un valor lógico verdadero, la siguiente tarea del futuro se ejecutará como si nada hubiese pasado, en caso contrario, se producirá un error de ejecución.

Cuando se publique Xailer 7 le recomendamos que eche un vistazo a las clases TFuture y TFutureTask. Observará que tienen muy pocas propiedades y métodos y que su uso es tremendamente sencillo. Espero que así se lo parezca. Por último comentar, que los futuros estarán disponible en todas las versiones de Xailer, incluso la personal.