Ver Mensaje Individual
  #4 (permalink)  
Antiguo 30/07/2006, 12:11
califa010
 
Fecha de Ingreso: enero-2006
Ubicación: Buenos Aires, Argentina
Mensajes: 299
Antigüedad: 18 años, 3 meses
Puntos: 5
Buenas,

El problema es que con ese for alcanzaste el "límite" del Flash Player para la máquina en la que estás reproduciendo el swf. Si una rutina, por ejemplo un for, tarda más de 15 segundos, el player muestra ese aviso al usuario, porque podría "colgarle" la máquina. Lo más probable es que el que vea la advertencia cancele la ejecución del script y entonces cualquier código que haya en el swf va a dejar de ejecutarse. En la práctica, la única manera de volver a "hacer algo" con ese swf es recargarlo,pero cuando vuelvas a llegar a ese for, va a pasar lo mismo.

Lo que podrías hacer es tratar de simplificar al máximo el código dentro del for. Por ejemplo, si hay otros loops anidados, tal vez algunos no sean realmente dinámicos y puedas escribirlos a mano. Si tenés llamadas a funciones dentro de ese for, podrías tratar de resolverlas dentro del mismo, sin llamar a funciones. En fin, tratar de optimizar al máximo todo lo que se ejecuta dentro del for (El resultado va a ser más "sucio", difícil de mantener y demás, pero a veces es la única alternativa).

Me pasó lo mismo que te pasa hace un tiempo en un módulo que imprimía fichas técnicas de autos. La interfaz gráfica te mostraba todas las versiones de un modelo; cada versión tenía categorías (dirección, suspensión, etc); dentro de cada categoría había "atributos" (ej: suspensión->trasera, delantera, etc), y a su vez, cada atributo tenía valores. Cada una de esas partes eran movieclips con su repectiva gráfica (vectorial, con alfas y gradientes, lo cual hace todo más pesado para el player) y era todo completamente dinámico, así que no había manera de hacer nada "a mano". (eran 5 loops anidados)

En la interfaz, funcionaba sin problemas porque tenía un páginado, o sea que no estabas cargando toda la información (y duplicando mc's) al mismo tiempo. Pero para imprimir,no quedaba otra porque el cliente quería la misma gráfica, y que en cada "print" estuviera la misma información TODA JUNTA (algunos modelos ocupan 13 páginas de impresas, para que te des una idea del tamaño).

Bueno, la única solución fue optimizar (y "ensuciar") lo máximo posible el código y eliminar el loop de más afuera (el primer for). En su lugar usamos setInterval() y como contador una variable global. Cada una de las vueltas "externas" se ejecutaba cada 30 milisengundos o algo así y con esa pequeña diferencia, el problema se solucionó. La conclusión que sacamos es que todo lo que hay dentro de un for cuenta para el límite de los 15 segundos que advierte macromedia en su documentación (no tengo el link a mano pero recuerdo haberlo leído en los livedocs). Pero, si en vez de hacer, por ejemplo, 5 vueltas de un for, hacés esos 5 procedimientos como llamadas a una función separadas por un intervalo mínimo de tiempo, para el límite de los 15 segundos cuentan como "independientes". O sea cada una de esas 5 llamadas tendría sus 15 segundos, en lugar de tener las 5, 15 segundos. Como te decía, eso solucionó el problema del aviso, aunque hubo que colocar una animación de "preparando impresión" porque igualmente tardaba bastante y dadas las circunstancias, no hubo manera de bajar ese tiempo.

Podrías probar con algo similar para solucionar tu problema. (Y también podrías fijarte si no hay muchos onEnterFrame o setInterval's que se ejecuten constantemente y afecten el rendimiento). Si querés pegá tu código; tal vez alguien vea la manera de simplificarlo y/o optimizarlo.

Suerte
Califa