Virtualización

Como no hay magia que valga, lo primero es hacerse con un programa de virtualización para instalar Windows. Los dos más conocidos son VMware Fusion y Parallels Desktop.

Cuando me pasé a Mac estuve leyendo bastante sobre ambos. Al final me acabó convenciendo más el primero, así que me compré una licencia de Fusion. Sin entrar en comparaciones, Fusion arranca bastante rápido, soporta copy/paste y drag&drop entre sistemas operativos, puedes acceder a las mismas carpetas desde ambos lados y tiene alguna otra característica interesante que ahora veremos.

No explicaré el proceso de instalación porque no es muy complicado y hay mucha información en la red, únicamente detallaré mi configuración por si sirve de ayuda.

Configuración de Windows y VMware

Yo tengo instalado un Windows 7 de 32 bits, FlashDevelop y poco más. Obviamente, si se necesitan más programas pues no pasa nada, pero es importante no tener procesos que se inicien en el arranque consumiendo memoria inútilmente, así que mejor instalar sólo lo imprescindible. Desaconsejo totalmente antivirus, ya que me parece muy difícil infectarse sin instalaciones ni navegación. Si se es muy desconfiado en este aspecto, mejor desactivar internet en Windows.

Importante desactivar el tema Aero, que para nuestro caso es absurdo. Yo utilizo el tema Windows 7 Basic y queda más que bonito. Y si no quieres dedicar ni un recurso a la estética, en "Herramientas de rendimiento", "Ajustar efectos visuales", activas "Mejor rendimiento" y te lo deja pelado.

En cuanto a la configuración de VMware, lo más relevante:

• Compartir: útil si vas a trabajar en Windows, ya que podrás acceder a cualquier directorio de Snow Leopard que añadas.
• Aplicaciones: aquí podemos añadir un acceso directo de FlashDevelop al Dock.
• Procesador: 1 núcleo. Esto quiere decir que el sistema virtual utilizará un nucleo del procesador, pero no de manera exclusiva. Nuestro Mac continuará utilizando los dos.
• Memoria: 1024 MB. En este caso la memoria sí que se reserva entera, es decir, que cuando Windows esté corriendo tendrá 1 giga reservado que no podrá utilizar Snow Leopard. Con Aero desactivado, para correr Windows y FD hay más que de sobras, así que no os preocupe darle "un poquito más" de este mínimo.
• Pantalla: sino tenéis dependencia de DirectX 9 (para juegos) ni utilizáis Aero, desactivar la opción "Acelerar Gráficos 3D".
• Disco duro: yo tengo una partición de 40 gigas, pero realmente bastaría con el espacio de Windows y poco más. Siempre es interesante cubrirse un poco para la memoria virtual, por si tomas muchos snapshots, porque al final siempre se acaban instalando cosas...

Una de las ventajas de virtualizar es que si la máquina no está corriendo, se puede cambiar toda la configuración, así que no tengáis miedo de ir probando configuraciones hasta que os sintáis cómodos. Pero si no queréis perder tiempo, con lo ya comentado, en un MacBook Pro Core 2 Duo de 2'66 y 4 gigas de ram, corriendo Windows 7 con FlashDevelop, más Flash, Chrome, Safari, Spotify y unos cuantos programas "menores" más, el ordenador "vuela" :)

Y un último apunte: cuando no se trabaje con la máquina virtual lo más cómodo y rápido es suspenderla, no apagarla, recuperando todos nuestros recursos y pudiendo volver luego en segundos.

Modo Unity

Una de las cosas más agradables y útiles de Fusion es su vista "Unity". En este modo, el escritorio de Windows desaparece y las aplicaciones aparecen como una ventana más de Mac. Perfecto, ¿no?

Y como comentaba antes, hacer un drag&drop de archivos, un copy&paste o cualquier típica operación entre programas funciona a la perfección. Un gran paso para sentirnos como si estuviéramos en un único sistema.

En busca del workflow perfecto

A pesar de que así está todo bastante integrado, falta una cosa básica: poder ejecutar películas en Flash desde FlashDevelop. Al principio pensé que mucha gente habría buscado una solución a esto y no sería difícil. No estaba equivocado ni nada...

Parece ser que en Parallels se puede instalar una herramienta llamada "Shared Applications" que te permite mapear programas, con lo que se puede configurar en FD la ruta a Flash.app (también vi que está lejos de ser perfecto y que muchísima gente tenía problemas). Desgraciadamente, en Fusion no existe nada similar.

Así que me puse a darle vueltas a la cabeza hasta encontrar un camino.

QuickSilver

QuickSilver es un programa que mucha gente del mundo Mac considera imprescindible y que sirve para lanzar aplicaciones rápidamente (esta es la utilidad más básica, realmente puede hacer mil cosas). Por ejemplo, yo para ejecutar Flash CS4 no lo busco en Aplicaciones ni el Dock, simplemente hago cmd+space, tecleo Fl y enter. Al principio puede parecer tonto, pero cuando te acostumbras no hay vuelta atrás.

Me acordé que el programa tiene un apartado llamado "Triggers" e indagé un poco. Un trigger permite asociar una acción (abrir una aplicación, correr un script, etc) a una combinación de teclas. Pensé que si podía correr un script funcionaría también con un jsfl... ¡y bingo!.

Así que abrimos Flash, creamos un nuevo archivo del tipo "Flash Javascript File" y escribimos la siguiente linea:

Lo guardamos en el escritorio como testmovie.jsfl

Ahora abrimos QuickSilver, vamos a "Preferences" y activamos la opción "Enable advances features" (no estoy 100% seguro que sea imprescindible, pero por si acaso). Después vamos al menú "Triggers", añadimos uno nuevo (parte inferior, en el +, "HotKey"), y nos sale una nueva ventanita. En "Select an item", sólo hace falta empezar a teclear el nombre de nuestro archivo y QuickSilver lo encontrará y nos pondrá por defecto la "Action" de "Open". Guardamos.

Nota: si al empezar a escribir no nos detecta el script seguramente sea porque no lo tiene indexado todavía. En el menú, junto a Triggers, hay una opción llamada "Catalog". Buscamos nuestra ubicación, en este caso Desktop, la seleccionamos y en la parte inferior, clicamos en el icono de refrescar (Rescan Source). Debería aumentar el número de elementos indexados. Ahora seguro que ya encuentra nuestro archivo.

Nota: QuickSilver no indexa todo el disco duro, sino que tiene unos directorios por defecto (el escritorio es uno de ellos). Si prefieres agrupar tus scripts en otro directorio tendrás que incluirlo a mano. Esto se hace también en "Catalog", en "Custom". Ahí añadimos un archivo o carpeta. Atención que si añadimos una carpeta, en el nuevo submenú que aparece, hay que indicar en "Include contents" que los queremos todos, sino coge el directorio pero no su contenido. Lo seleccionamos y volvemos a refrescar para que lo indexe.

Ahora que tenemos nuestro trigger, sólo falta asignarle una tecla. Click sobre la palabra "Hot Key" (o en la "i" del menú inferior, "Trigger Info"), "Edit" y ponemos nuestro atajo. En mi caso he elegido "alt+z". Para activar el trigger, desactivar-activar una vez el check de la izquierda.

¡Voilá, ahora ya podemos ejecutar en cualquier momento nuestra película desde FlashDevelop! (realmente desde cualquier sitio :p )

Guardar y compilar

Aunque ahora el flujo es bastante bueno, todavía falta que con el mismo comando se pueda guardar la clase que se está modificando y luego saltar a Flash para compilar. Sino eres tan purista-pesado-friki como yo, con la opción anterior es suficiente; si lo eres, a seguir leyendo.

La primera idea era buscar un script que pudiera guardar en FlashDevelop e intentar correrlo luego con QuickSilver, de la misma manera que hemos hecho con el jsfl. Lo primero, no encontré la forma de generar dicho script, y lo segundo, en QuickSilver con un único comando no puedes ejecutar dos opciones (realmente si he visto una forma, pero no entendí ni la mitad).

Leyendo leyendo fui a parar a un post de un tío que manipulaba Spotify vía AppleScript, así que ahí vi otro camino: crear un applescript que se comunicara con FlashDevelop y ejecutarlo desde QuickSilver también. Como seguía encontrando el escollo de "un comando, dos scripts", primero me puse a buscar la forma de poder hacer un "TestMovie" con AppleScript también, para tenerlo todo en un único archivo. Así que descarté el jsfl inicial y adapté el código del Spotify a Flash CS4.

Mac Os cuenta con "Apple Script Editor", que va de coña para ir probando los scripts. Lo abrimos, creamos un nuevo fichero y copiamos este código:

Este código pone en primer plano Flash o lo abre si no lo está, y simula un clic en la opción "Test Movie". La traducción del script es esta:

menu item "Test Movie" of menu "Control" of menu bar item "Control" of menu bar 1 of application process "Adobe Flash CS4" of application "System Events"

Increíble, ¿no?

Muy importante: es probable que el script os arroja un error similar a este "El acceso a los dispositivos de ayuda está desactivado". Esto pasa porque el comando "System Events" no puede operar. Para que funcione, hay que ir a "Preferencias del sistema" (sí, de Mac), "Acceso Universal", y abajo activar "Activar Acceso para dispositivos de ayuda".

Pausa para desahogo: ¿quién carajo sabe esto? ¿Por qué en todos los tutos que vi sobre AppleScript no lo comentan? Lo encontré tras un buen rato de búsqueda en un foro de frikis de World of Warcraft que lo utilizaban para configurarse nosequé del juego... En fin, para llorar.

Nota: Otra cosa que descubrí por la vía dolorosa es que los separadores del menú cuentan como 1, de ahí que "Test Movie" corresponda al número 8 aunque esté en la posición 6. Ojo con esto si intentais manipular cualquier otro comando.

Cuando por fin pude ejecutar el script y ver que funcionaba, fue fácil pensar que para FlashDevelop sería lo mismo. Así que me dispuse a probarlo. Una cosa que mola mucho del editor de AppleScript que si pones el nombre de un programa que no reconoce (yo por ejemplo ponía -tell application "FlashDevelop" to activate-), al ejecutar te pregunta dónde está y te ofrece la lista de programas (¡incluso los de Windows!) para resolver el nombre correcto:

Así que puse la ruta para llegar hasta el menú "File > Save" en FD y corrí el script, pero no funcionaba por un error de base que tarde un poco en detectar:

Efectivamente, el menú de FlashDevelop cuando tiene el foco no es el del programa de Windows, sino el del "wrapper" de Mac, así que otro "fail" para la lista.

Vuelta a leer tutoriales sobre AppleScript y posibilidades y encontré algo superútil: igual que se pueden simular clics de ratón se pueden simular pulsaciones de tecla. Así que tras unas pruebas pude comprobar que ganando el foco del programa y lanzando un "Ctrl+S" (estamos en Windows) guardaba el documento. ¡Por fin!

Nota: el 1 corresponde a la "s" en key code. Aquí os podéis bajar un pdf con los "key code" de un teclado Mac. Lo necesitaréis para configuraros vuestros propios atajos.

"Pues ya sólo queda ponerlo todo en un script", pensé, pero había una última sorpresa: el script saltaba a FD, acto seguido a Flash y compilaba, pero no guardaba. ¿WTF? Cuando volvía a ejecutar únicamente el código de guardar funcionaba, pero me di cuenta que tardaba unas décimas de segundo, y pensé que seguramente al intervenir la máquina virtual no era lo suficientemente rápido al enviar el comando y ganaba el foco Flash antes de poder guardar. Esta vez me costó apenas unos minutos encontrar una instrucción "delay", y efectivamente, era eso.

Finalmente, nuestro script queda de la siguiente manera:

Lo dejo para descargar aquí: http://llops.com/descargas/applescripts/save-test-movie.scpt

Dos cosas a tener cuenta:

1. la ruta que hay en el script para FD y Flash quizá no corresponda con la vuestra. Setearla como he comentado antes.
2. el delay de medio segundo es suficiente para mi máquina, pero quizá en otras deba aumentarse a un segundo o más.

Una vez guardado el script, volvemos a QuickSilver, repetimos los pasos para hacer un trigger con nuestro nuevo script, y ahora sí que sí, con una tecla podemos guardar nuestro fichero activo y compilar en Flash (ueeeee).

Guardar todos los archivos y compilar

Pero... ¿y si se quieren guardar todos los archivos en vez de únicamente el que tiene el foco? Esta es una opción que utilizo mucho, ya que voy saltando de archivo en archivo, picando código y compilando "de golpe". Pues otro problema, porque FlashDevelop tiene un atajo para "Save" y "Save as...", pero no para "Save all".

Esta vez no tuve que perder mucho tiempo, porque en la "investigación" inicial de FlashDevelop descubrí los "macros" (eso a lo que nunca se presta atención). Vamos a "Edit macros..." (Ctrl+F10), creamos uno nuevo, y en "Entries" añadimos el siguiente comando:

Asignamos el shortcut que queramos y guardamos. Ahora podemos añadir dicho atajo en nuestro script y cada vez que compilemos guardará todos los archivos abiertos.

Cerrar la película de Flash y volver a FlashDevelop

Y ya para acabar (lo juro), un script tonto que mejora un poquito más mi flujo:

Simplemente pone el foco en Flash, cierra la película y asigna el foco a FD. En mi caso tengo "cmd+0" para guardar/compilar, compruebo que va bien y pulso "cmd+9" para cerrar el test y volver a FlashDevelop para seguir trabajando.

Nota: a tener en cuenta que si no hay una película en test cerrará el archivo fla. Está con el método del "click" porque con teclas (cmd+w) no acaba de ir bien... no sé porqué...

Conclusión

Si no quieres renunciar a seguir trabajando con FlashDevelop y Flash Professional en Mac, hay mecanismos suficientes para tener un workflow "perfecto" en el sistema de la manzana. Todo el tema de guardar/compilar quizá sea un poco geek, rebuscado o como se quiera llamar, pero funciona. Y de eso se trata la tecnología, de ponerla a nuestro servicio para facilitarnos las tareas.

Por otro lado siento lo larguísimo del post. Soy consciente de que lo podía haber acortado mucho, pero QuickSilver y AppleScript me han parecido herramientas terriblemente potentes, y creo que ha sido interesante hablar sobre ellas y que cada uno le saque partido no sólo para esto, sino para lo que se le pueda ocurrir que facilite los flujos de trabajo diarios. Me encantará si a alguien se le ocurren nuevos scripts y los comparte.

Por último, espero el comentario que diga "Pero vaya matada! si esto se puede hacer así y así de fácil" :) Aún así, volvería a pasar por este proceso. A veces nos tiramos tanto tiempo rodeados de Flash que nos creemos que únicamente somos programadores Flash, cuando al final ser programador es tener una base para enfrentar problemas y sacar soluciones.

Con mucha ayuda de Google, claro.

21 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2010

Entre las nuevas características encontramos:

• Tweens con Bezier (por fin!)
• Bezier through, un nuevo sistema en el que se definen los puntos a trazar en vez de los puntos de control de la curva. Es una idea genial, ya que es infinitamente más intuitivo. Me preguntó porqué nadie lo habrá hecho antes...
• Se pueden pausar y reanudar las animaciones
• Se pueden crear secuencias de animaciones
• Se puede saltar a cualquier punto del tween
• Se puede animar a nivel hexadecimal
• ...

Si quieres ver de todo lo que es capaz, en el site encontrarás una tabla comparativa de las clases con todas sus funcionalidades.

Y a pesar de las características añadidas, el peso sigue siendo mínimo (8kb), y la velocidad y rendimiento tan increíbles como antes.

En el artículo anterior comentaba que TweenLite tenía alguna debilidad, pero TweenMax las cubre todas. Personalmente, ahora sí puedo decir que TweenLite, junto con TweenFilterLite y TweenMax, es el mejor paquete de animación que podemos encontrar para ActionScript.

Descargar TweenMax

6 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008

Algunas de ellas se convirtieron poco menos que en míticas. ¿Quién no recuerda a Robert Penner por sus revolucionarias librerías de Easing, o a Moses Gunesch por su FuseKit?

Con la llegada de AS2 vimos algún avance pero muy pobre, y con AS3 yo pensé que ya no haría falta recurrir a soluciones de terceros, pero estaba equivocado. Aunque es cierto que con los paquetes fl.transitions, fl.motion, fl.transitions.easing y fl.motion.easing (en los que ha trabajado Penner, por cierto) se puede crear todo tipo de animaciones, a la hora de la verdad las clases son poco prácticas, ya que la sintaxis es engorrosa, no son suficientemente intuitivas y sobretodo son muy pesadas.

Por suerte, la comunidad AS se movió bastante rápido y en el 2007 ya había disponibles varios kits de animación para AS3. La mayoría de gente optó por Tweener, entre ellos yo, pero hace cosa de 4 meses probé TweenLite y quedé encantado. Desde entonces, cuando tengo que animar por código, TweenLite es mi primera opción.

Podría resumir TweenLite (que cuenta con versiones tanto para AS2 como para AS3) en tres características: muy fácil de usar, muy muy rápido y muy muy ligero.

Fácil

Como en casi todos los kits de animación, la sintaxis es muy fácil e intuitiva. No hay que crear ningún objeto, simplemente llamarlo y pasar 3 argumentos: el objeto a animar, el tiempo y las propiedades que deben ser animadas. Por ejemplo:

Dispone de muchas funciones avanzadas, como métodos onComplete, onStart y onUpdate (pudiendo pasar parámetros), delays, posibilidad de animar por frames, tweens simples para alpha, volumen, color...

Lo mejor es ir a la web para descubrir todas sus características. Ahí encontrarás también un ejemplo donde se ve lo fácil que es animar cualquier propiedad.

Rápido

El código está excelentemente optimizado, por lo que TweenLite es capaz de manejar cientos e incluso miles de tweens a la vez sin muchos problemas.

El propio autor tiene en su web un test comparativo entre distintos engines donde TweenLite marca diferencias.

¡Ojo al seleccionar el Tween de Adobe porque realmente te cuelga el navegador! Poner un número de instancias bajo.

Y si te quedan dudas, puedes echar un ojo también a esta serie de benchmarks de Moses en los que TweenLite obtiene unos fantásticos resultados.

Veréis que en los test hay un "candidato" llamado Go que destaca también por sus resultados. Go no es en sí un paquete de animación, sino una especie de framework desarrollado por Moses para crear nuestros propios tweens.

Y como una imagen (o un swf) vale más que mil palabras, he desarrollado un pequeño ejemplo (click para empezar/parar) donde TweenLite maneja cerca de 4000 shapes por segundo con fluidez. Quite impressive, no?

Descargar ejemplo

A modo de comparativa, hice el mismo ejemplo con Tweener y la diferencia es abismal. En el código dejo comentada la función por si alguien quieren hacer las pruebas, pero no añado las clases de Tweener para que no pese demasiado la descarga.

Ligero

Lo mejor es que TweenLite (que realmente es una clase con unas 300 lineas de código útil) sólo añade a nuestra película 3kb de peso.

Esto lo hace ideal para todo tipo de campañas online donde el tema del peso es crítico (precisamente yo lo probé cuando tuve que hacer un banner que no podía superar los 20kb). Este factor ha hecho que muchísimos desarrolladores y agencias apostemos por él.

Pero aún hay más...

TweenFilterLite

TweenFilterLite es una clase separada que extiende de TweenLite para poder animar todo tipo de filtros y otras propiedades como brillo, contraste, saturación, etc.

El mayor objetivo de Jack Doyle, autor del engine, es mantener siempre bajo mínimos el peso de las clases, de ahí que optara por separar funcionalidades. Utilizar las 2 clases sólo añade 6kb a nuestra película.

TweenLite me encanta, pero TweenFilterLite es una pequeña maravilla. Aunque no haya necesidad de animar, es infinitamente más fácil cambiar cualquier propiedad de una matriz mediante tween que mediante código.

En el mismo sitio donde se puede descargar, encontrarás un ejemplo donde se muestra todo lo que se puede hacer con esta clase. Visita obligada.

Y otro ejemplo de cosecha propia. Con una simple linea de código se pueden conseguir efectos como estos (click para cambiar la composición):

Descargar ejemplo

Contras

Como ya he comentado, el gran objetivo de este kit es que sea liviano. Las 2 clases del paquete suman 50kb frente a los más de 100kb de Tweener contenidos en 9 clases. Esto quiere decir que TweenLite no tiene tantas funcionalidades como este último.

De todas maneras, estas funcionalidades podríamos calificarlas de muy avanzadas, y seguro que en la gran mayoría de casos TweenLite nos satisfará completamente.

Con todo, hay algo que sí podemos echar mucho en falta: no soporta tweens con Bezier. Si para tus animaciones utilizar curvas es un requisito sine qua non, de momento necesitarás otro engine.

Y digo de momento porque Jack está trabajando en lo que llama TweenMax, clase que extenderá de TweenLite para agregar funcionalidades más potentes como esta. Gran noticia :)

Resumiendo

La animación por código es algo que prácticamente todos hacemos, ya no sólo programadores, sino también muchos diseñadores. Debido a esta popularización hoy se pueden encontrar muchos kits de animación (yo conozco hasta 7 para AS3). Entre tantos, puede ser difícil elegir uno.

Durante todo el artículo he estado continuamente haciendo comparaciones con Tweener, y lo he hecho precisamente porque he trabajado mucho con este último y me parece un gran engine, más que recomendable.

Personalmente creo que no se puede decir que uno es mejor que otro: cada uno tiene un enfoque propio y prioriza determinadas cosas.

Aún así, el autor de TweenLite ha sabido crear un paquete que, con un impacto mínimo en el peso de nuestro archivo, permite animar fácilmente un número enorme de objetos sin que nuestra aplicación se resienta. Si todavía no lo has probado, dale una oportunidad y seguro que no te arrepentirás.

Descargas

TweenLite

TweenFilterLite

13 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008

Su firma es:

Pero... ¿por qué existe este método?

Si utilizamos un movieClip que tenga código en alguno de sus frames o más de un frame (sino sería compatible con Sprite) y éste cuenta con una clase asociada, si la clase no extiende de MovieClip, el compilador arroja el siguiente error:

1180: Call to a possibly undefined method addFrameScript.

En el artículo Programando en AS3 desde Flash CS3 (I) vimos que, en AS3, todo lo que hacíamos en el IDE de Flash acababa "transformándose" en clases.

Pues bien, addFrameScript es la forma que tiene el compilador para coger el código que tenemos dispersado en nuestros movieclips y añadirlo a nuestra clase. De ahí que si se dan las condiciones que hemos visto, el compilador nos muestra ese error, ya que intenta buscar un método addFrameScript en una clase que no lo define.

Sacando partido de addFrameScript

Utilizando esta función indocumentada y la nueva clase de AS3 FrameLabel, escribí hace algún tiempo una sencilla clase que nos permite añadir y eliminar código en un frame que contenga una o más etiquetas. La clase se llama FrameScript.

Para instanciar una nueva clase FrameScript debemos pasar un MovieClip en el constructor.

Una vez creada, disponemos de dos métodos públicos:

Utilizar etiquetas en vez del número del frame es mucho más intuitivo y permite modificar la longitud del timeline sin que nuestro código falle.

Algunas formas de utilizar FrameScript

Como variable de clase en caso que tengamos que acceder más de una vez a nuestra instancia:

Como variable local en caso que tengamos que acceder una única vez para asociar código:

Sin asignar variable (forma breve):

Y un ejemplo muy simple para ilustrar su uso: dos instancias de un mismo movieclip cuyo comportamiento es modificado al marcar el check.

Descargar ejemplo

Algunas consideraciones

Gracias a este método podemos mantener todo el código encapsulado en nuestra clase sin necesidad de programar en la linea de tiempo. Incluso podemos añadir nuevas funcionalidades en tiempo de ejecución, no sólo de compilación.

Aunque en líneas generales es una buena práctica no tener el código "escampado" por el fla, el otro extremo puede ser igual de malo. Es más sencillo tener algunos frames con instrucciones sencillas tipo stop() que intentar sacar todo el código fuera.

Por otro lado, la mayoría de veces que un programador necesita meter código en un movieclip suele ser para sincronizar las animaciones. En estos casos sí que puede ser más conveniente utilizar FrameScript antes que tener un bloque de código similar a esto:

MovieClip(parent).stop();
MovieClip(parent).proyectil.visible = false;
MovieClip(parent.parent).finAnimacion();

Por último, addFrameScript es un método indocumentado. Esto significa que Adobe no garantiza que en futuras versiones del Flash Player se soporte, y en ese caso nuestras películas fallarían. De todas formas, es muy improbable que suceda algo así y nunca he visto que se haya dado este problema con otros métodos indocumentados.

Update (29/03/09): Iván Gajate me advierte de un error ya que el método addFrameScript trabaja con índice cero y se debe restar un frame para que asigne correctamente. La clase y los ejemplos ya están actualizados.

>> Descargar la clase FrameScript

7 comentarios
Compartir en Twitter | Compartir en Facebook

© llops blog 2008