Archivo por meses: octubre 2020

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.

Exprimiendo el FOR EACH de Harbour

La cláusula FOR EACH que Harbour incorporó al lenguaje CA-Clipper fue una gran mejora, pero hay mucha gente que sólo lo utiliza de su forma más básica:

FOR EACH value IN aValues
  ? value
NEXT

Sin embargo ofrece multitud de posibilidades. Vamos a enumerar unas cuantas:

  • Iterar sobre más de una variable:
    FOR EACH a, b, c IN aVal, cVal, hVal
      ? a, b, c
    NEXT
  • Establecer orden descendente:
    FOR EACH a IN aVal DESCEND
      ? a
    NEXT
  • Asignar caracteres de una cadena de forma directa: (atención a la @)
    s := "abcdefghijk"
    FOR EACH c IN @s
      IF c $ "aei"
        c := Upper( c )
      ENDIF
    NEXT
    ? s // AbcdEfghIjk
  • Control por POO sobre las variables de iterador:
    • :__enumIndex() retorna el actual ordinal en la iteración. El equivalente a nFor
    • :__enumIsFirst() retorna si es el primer elemento en la iteración
    • :__enumIsLast() retorna si es el último elemento en la iteración
    • :__enumBase() retorna la variable base que está siendo procesada. Útil cuando se procesan más de una variable.
    • :__enumValue() retorna el valor de la variable que está siendo procesada. Útil cuando se procesan más de una variable.
      FOR EACH a IN aVal
        ? a:__enumIndex()
      NEX

Harbour incluso permite modificar como se debe de recorrer la iteración utilizando los métodos :__enumStart(), :__enumSkip() y :__EnumStop(). Tenéis un ejemplo de uso en el fichero \harbour\tests\foreach2.prg.

Espero que os haya sido de utilidad.

Un saludo

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 )

Para controlar el resultado final del proceso:

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

Y por último ejecutar el proceso asíncrono:

oTask := oFuture:AddThreadTask( bWork )

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.