Carlos Rovira

Respuestas de foro creadas

Viendo 15 publicaciones - del 1 al 15 (de un total de 16)
  • Autor
    Publicaciones
  • #6686

    Carlos Rovira
    Jefe de claves

    Estupendo José, ya sabes que puedes darle promoción a tu blog desde madeinflex y postear o añadir entradas a la sección “ejemplos y trucos”. En general son sugerencias para participar en MIF y dar más visibilidad a lo que quieras compartir en la comunidad.

    Gracias! 🙂

    #6683

    Carlos Rovira
    Jefe de claves

    Me alegro que lo hayas solucionado José, y gracias por volver y compartir la solución! 🙂

    #6680

    Carlos Rovira
    Jefe de claves

    Me temo que solo con Flex no vas a poder hacerlo. FSCommand requiere que el SWF se ejecute con el proyector de Flash. Si puedes empaquetar con Adobe AIR, si que es más sencillo y varias formas.

    Por último, si tiene que ser un Flex en navegador hay otra opción algo más enrevesada: Se trata de hacer una app con Adobe AIR pequeñita que sea la que puede abrir el .exe, desde Flex en el navegador puedes comunicarte con esta mini app adobe air por LocalConnection. En esa comunicación la aplicación Flex le “pediría” a la app AIR que abra el .exe

    Espero que te sirva…

    #6630

    Carlos Rovira
    Jefe de claves

    Hay varias formas de modificar las propiedades de los objetos asociados a un dataprovider. Una de ellas es el two way binding (la @ en el binding, ej: @{migar}). Otra forma es que un evento CHANGE y usar una función donde asignes el valor (ej: dentro de esa función algo tipo data.propiedadFecha = dateControl.selectedDate).

    #6627

    Carlos Rovira
    Jefe de claves

    Hola Leonardo,

    veo que usas el mx:DataGrid en vez del s:DataGrid (spark). Si te es posible te recomiendo usar este último ya que lo que planteas está en desuso.

    En general el problema que plateas suele ser debido a un reciclaje incorrecto de los renderers, con spark debes conseguir un estilo de programación más consistente a lo largo de Flex (no solo con DataGrids) que te ayude a evitar estos problemas conforme entiendas su uso. La clave está en que los renderers se “reutilizan” para distintos datos y por tanto debes asegurar un ciclo de vida correcto para que se redibujen y ofrezcan un estado consistente conforme hago scroll por la lista o grid.

    Mira este enlace con un ejemplo de s:Datagrid y un itemrenderer con un DateField a ver si te ayuda. En este se usa un two way binding para recibir el dato y también para sobreescribirlo.

    #6561

    Carlos Rovira
    Jefe de claves

    A veces es mejor replantearse estos temas. Es una pena, pero es así…

    saludos

    #6555

    Carlos Rovira
    Jefe de claves

    Como aquí se da una regresión de una versión particular de Flex y además una aplicación que lleva varios años en desarrollo, quizá te deberías de replantear todo sabiendo lo que sabes ahora.

    Mi consejo es que busques algo más por la web sobre el error #1009 y que veas si alguien ofrece alguna solución. Si por ese lado no consigues nada, quizá deberías replantear si merece la pena pasar a Modulos o no.

    El migrar una aplicación cuando no se ha hecho de forma progresiva suele ser costos ya que suelen darse muchas malas prácticas y problemas, por lo que en caso de plantearte una migración, esa opción puede requerir tiempo y costes significativos que seguramente tendrás que validar con otras personas.

    #6552

    Carlos Rovira
    Jefe de claves

    Por lo que dice el ticket parece que es una regresión en esa versión (no especifica si hay fix después, pero entiendo que en versiones posteriores ese problema no existe…para mi hace mucho desde que estuve con la 4.0 y ya no lo recuerdo, poco más te puedo decir).

    ¿No podéis pasar a una versión más moderna? (ya puestos Apache Flex 4.12). Ten en cuenta que la 4.0 es muy antigua.

    #6550

    Carlos Rovira
    Jefe de claves

    Puede ser esto?

    https://issues.apache.org/jira/browse/FLEX-28446

    Estás usando Flex 4.0?

    #6548

    Carlos Rovira
    Jefe de claves

    Correcto, lo mejor es proyecto por modulo y puedes tener una o varias librerías compartidas (según tu necesidad) linkadas como RSLs desde la aplicación y como “external” en tus módulos. Eso es lo más óptimo.

    Suerte! 🙂

    C.

    #6546

    Carlos Rovira
    Jefe de claves

    Buenas Guillermo,

    El problema que tienes es que la librería genera un SWC y no el SWF, el modulo debe ser generado como SWF y lo debes colocar en tu servidor como un recurso más para que pueda ser cargado. A este respecto mi consejo es que o bien crees el modulo dentro de tu proyecto principal (lo más sencillo) o crees un nuevo proyecto donde resida el modulo. Sea cual sea la opción el SWF generado lo debes colocar, como te decía, como recurso estático y cargarlo con el ModuleLoader.

    Dado que el modulo usará classes y componentes de la librería tendrás que hacer depender dicha proyecto (ya sea el de aplicación o el de modulo, si has optado por esta opción) de tu librería.

    Por último y para mejorar la configuración, considera el usar las librerías como RSL (esto no es necesario pero es recomendable)

    Ten en cuenta que una librería son clases / recursos que no son “instancias” solo “definiciones” que se podrán usar en un momento dado en la aplicación.

    En cambio una aplicación o modulo es un ejecutable que “instancia” clases y componentes y por tanto genera en memoria un uso de los mismos.

    Para terminar a la hora de cargar, como te decía en el anterior hilo, la carga es con el ModuleLoader y se le pasa la url a cargar. En este caso “/path/to/module/mimodulo.swf”. Es decir un recurso estático como si cargaras una imagen. Lo cual difiere mucho de “instancias” una clase de la librería y *hacer uso* de la misma. Por tanto, estás “cargando” el modulo como recurso externo y no declarando una variable o instanciandolo.

    #6540

    Carlos Rovira
    Jefe de claves

    Buenas Guillermo,

    he cambiado el hilo de foro ya que tenemos el foro de Flex SDK que es más apropiado.

    la forma más sencilla de hacerlo es hacer que cada una de tus librerías tenga un modulo insaciable como punto de entrada a dicho modulo.

    Esto generará un SWF que podrá ser cargado solo por otro SWF principal (no por si solo).

    En la zona de la aplicación que gestiones la carga tienes que usar un ModuleLoader y cada opción del menu cambiara la url de carga de dicho componente para ir cargando uno modulo u otro.

    En el siguiente ejemplo el parámetro url debe de cambiar conforme seleccionemos una opción de menú u otra:

    • Esta respuesta fue modificada hace 5 años, 2 meses por  Carlos Rovira.
    • Esta respuesta fue modificada hace 5 años, 2 meses por  Carlos Rovira.
    #6529

    Carlos Rovira
    Jefe de claves

    Hola Leonardo,

    los remote objects y cualquier otro tipo de RPC funcionan de forma asíncrona haciendo una llamada y esperando una respuesta (ya sea un resultado o un fallo de operación) que generará un hilo de ejecución independiente del hilo de renderizado del player.

    Dicho esto, lo habitual es hacer una carga de datos maestros al comienzo de la aplicación, modulo o pantalla que los va a usar. De forma que tengamos preparados los mismos para su futuro uso.

    Seguidamente en el momento oportuno puedes hacer la llamada a los datos de una zona concreta usando los datos maestros que ya tendrás de ante mano.

    Los frameworks que comentas te servirán para mejorar la organización de tu código y su uniformidad a lo largo toda la aplicación (es decir, tener todo programado con el mismo estilo y metodología), pero no tiene nada que ver con tener claro como y cuando tienes que hacer una llamada.

    Lo mismo te digo para el tema de eventos encadenados. En general no te los aconsejo ya que todo debe ser lo más sencillo y desacoplado posible para evitar que en un momento dado cambies algo y se rompan funcionalidades por una dependencia no deseada.

    Lo dicho, separa llamadas, prepara datos precargandolos y en general simplifica e intenta que todo sea lo más sencillo posible.

    #6456

    Carlos Rovira
    Jefe de claves

    Alvaro,

    la siguiente librería es un port de iText (conocida librería de Java) para generar y leer PDF:

    https://github.com/sephiroth74/purePDF
    http://www.sephiroth.it/weblog/archives/2010/02/pdfreader_for_purepdf.php
    http://www.sephiroth.it/weblog/archives/2010/02/purepdf_a_complete_actionscript_pdf_l.php

    Además, el autor es Alexandro Crugnola (alias, Sephiroth), un crack del AS3 toda la vida.

    Yo no la he probado pero solo por las referencias creo que merece la pena.

    Conforme hagas pruebas te agradecería que comentases que tal la experiencia.

    #6451

    Carlos Rovira
    Jefe de claves

    Hola Alvaro,

    has llegado al sitio oportuno :). El objetivo de estos foros es justo eso que la comunidad aporte y ayude a solventar dudas y problemas. Para ello es importante que planteemos temas lo más concretos posibles y que estén bien definidos para que la ayuda sea factible. Muchas veces los hilos en los foros terminan por no ser respondidos o derivan en poca concreción debido a que no invertimos el tiempo necesario en formular las preguntas adecuadas y con la información precisa.

    Bienvenido! 🙂

    Carlos

Viendo 15 publicaciones - del 1 al 15 (de un total de 16)

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase