![]() |
Problema con limite de instancias de objetos (TBitBtn)
Buenas tardes,
Les comento lo siguiente: Hice un módulo muy padre y toda la cosa que a resumidas cuentas permite a un usuario crear objetos en un contenedor (tpanel - emulando las celdas de excel) pero mi aplicación a pesar de que los objetos se destruyen cuando se dejan de usar ya sea eliminandolos manualmente o cuando se carga otro reporte (es un reporteador realmente)... llega un momento en que me marca "Out of resources" Mi pregunta es: ¿Existe algún límite configurable desde la aplicación (en este caso, desde alguna directiva de compilación) que resuelva este problema? Utilizo Windows Vista Bussines, Delphi 2006 y la aplicación es de tipo Win32. La clase de donde se crean los objetos es heredada de TJvXPButton (de los jedi, aunque con TBitBtn se presenta el mismo problema) con algunas características especiales. Presiento que está muy "pesado" ese control... pero tengo 3Gb de memoria y cada reporte solo crea 1300 objetos de ese tipo, se corre un reporte a la vez... alguien puede orientarme a la solución? o de plano mi pregunta está muy fumada? Espero sus aportes y gracias de antemano. |
Como opinion personal; creo que lo que estas haciendo es un Cruft... por qué no pegas un pantallazo de lo que quieres para ver que podemos hacer (de otra forma, claro está).
|
Cita:
Gracias de todos modos por tu aporte. Alguien puede contestar a mi pregunta original? ¿Existen restricciones de número de instancias o de memoria asignada para tales? Gracias de antemano |
Cita:
Cita:
|
Cita:
Esto es precisamente lo que me temía... que no respondieran a la pregunta original y quisieran desviar el asunto como diciendo: NO SE... PERO SE ME OCURRE QUE... Ni hablar. :( P.D. En C# de Visual Studio no tengo problemas con esto... pero lo necesito en Delphi. |
Cita:
Cita:
Salud OS |
Cita:
|
La verdad es que con esa actitud, es muy raro que alguien se anime a responderte. Si necesitas hacerlo "a tu manera" basta con decirlo, no hace falta criticar a un valioso miembro de esta comunidad, que dicho sea de paso, rebosa calidad en todos sus mensajes y siempre se aprende algo de él. Si tú no sabes apreciar esa calidad... ejem, es problema tuyo.
¿sólo 1.300 objetos? ¿sólo?, desde luego no es un buen diseño, y precisamente esa es la mejor respuesta que se te puede dar, siempre con ánimo constructivo, como ha hecho cHackAll al brindarte su ayuda, que por cierto, no está obligado a hacerlo. Saludos |
Cita:
Bueno, independientemente de que el iniciador del hilo (en mi opinion), haya sido algo antipatico; creo no poder resistirme a lanzar un par de ideas al aire a ver si son de utilidad; en C# existen los Garbage Collectors que son de gran utilidad, pero a veces ocacionan que el desarrollador pierda conceptos de manejo de memoria y objetos (especificamente su adecuada liberación); nativamente Delphi no consta con lo anteriormente dicho y aunque existen componentes yo tengo mis reservas. En este caso, es probable que se estén creando los N objetos, y al no ser adecuadamente liberados los mismos sean incrementados en cada ocacion, en dicho contexto habría que analizar el codigo. Ahora; cuando en mis comienzos hice lo que el inciador del hilo hizo (con fines de edicion de datos), aprendi que ésta no es una buena practica; solamente basta con imaginar que sucedería si Excel usara para cada celda un TEdit... La solucion mas "facil" es el uso de componentes; StringGrids (como comentaba egostar), TListViews, etc., en un nivel mas experto de programación desarrollar emulaciones y pintados en Lienzos(Canvas) (Aunque para facilidad de programación tambien existen un buen numero de componentes de terceros que hacen esto). nuk3zito; si quieres adjuntar un pantallazo (como te sugeri al comienzo) talvez otros miembros te puedan dar ideas (componentes que asemejen comportamiento)... si quieres continar con la actitud inicial pues dudo que obtengas resultados. En mi opinion solo di una critica constructiva para evitarme éste engorroso post. PD; Si tenemos 80 Gb. de RAM (hipotetico), y conseguimos que nuestro programa tenga acceso al 100%, si el programa tiene Memory Leaks en algun momento dirá "Out of resources". Un abrazo a egostar y a Lepe. Saludos |
yo creo que no liberas correctamente los panels creados (un TPanel en memoria tampoco debe ocupar mucho, y 1300 no suena a muchos) o el objeto que sea. De todas maneras, crear un grid de panels tipo excel es algo un poco...cruft...digamos ¿por que no nos explicas mejor que es lo q quieres hacer y te podemos echar mejor una mano?
PD : sin decir nada nuevo : ¿no te iria mejor usar un TStringGrid o un TListView? |
Respuesta a tu pregunta:
NO, no existe un limite configurable. para crear los objetos que usas? un TList, un arreglo? o como? ojala puedas poner codigo, a lo mejor es algo que programaste mal o un bug del delphi |
Que tal,
cHackAll, me disculpo por mi respuesta agresiva, la verdad es que algunas veces estoy a la defensiva cuando presiento que van a desviar el tema (ya me ha pasado muchas veces, son pocas las ocasiones en que he tenido serias dudas) y creo que en esta ocasión esto me llevó a iniciar con el pie izquierdo; aparte de todo, te agradezco por dar una respuesta a lo que necesito. Mira, si se que el Framework de .NET tiene su Garbage Collector y es bastante eficiente y he supuesto desde que se me presentó el problema que Delphi no maneja adecuadamente su basura, a pesar de que desde el Delphi 2005 lo han estado prometiendo (uso el 2006, desconozco si alguna versión posterior lo maneje adecuadamente). Es precisamente esto lo que quería indagar en este foro, y es que en realidad nunca se acaba la memoria de mi PC y ni siquiera se ve algo de actividad anormal en este aspecto (ni con los 1300 objetos cargados por el usuario en tiempo de ejecución). A continuación adjunto un pantallazo que muestra un poco del tema de lo que la pantalla debe hacer (en este proyecto no soy el líder, así que recibo órdenes... órdenes de hacer lo mismo que se hizo en C# de manera muy similar en Delphi) ![]() Los botones se colocan en tiempo de ejecución cargadas sus propiedades y propiedades "agregadas" desde una tabla (para eso utilicé la herencia) los cuales al dar click o al llamar su menú contextual hacen o muestran algo. Las rutinas para las llamadas del menú contextual y el código de los eventos es genérico, es decir, se liga a cada "botón" cargado en la pantalla. Las propiedades que se agregaron son tan genéricas como simples variables (accesadas desde sus propiedades obviamente) de tipo integer, string, real, etc. ¿Por que debe ser botón? Porque al usuario se le indica de manera implícita que le puede dar click (algo obvio) aunque no estoy casado con la idea de tener que usar botones, simplemente fue lo que en su momento se nos ocurrió presentar al usuario. Si encuentro otro componente que sea bastante más ligero y que no me presente los mismos problemas, creo que lo utilizaré. La manera de liberar los objetos una vez que ya no se requeiren en el reporte actual, es de la siguiente manera:
Tal vez esto no sea de la manera adecuada. Pero no se de que otra manera debería liberar los objetos... FreeAndNil entiendo que hace lo mismo pero me pone los valores en null, lo cual lo considero innecesario puesto que elimino mis objetos del StringList que utilizo. Cita:
Cita:
Lo de la memoria por cierto... la memoria de la instancia de la aplicación no se la pasa creciendo, por lo que ni con 3Gb ni con 80Gb se resolvería el problema. Es por eso que acudí al foro para ver si alguien habría tendio antes un problema similar y ver que diablos pudiera estar pasando. Aún y los roces que se presentaron desde un principio, agradezco ahora si de manera sincera tu aporte. He tenido buena experiencia con foristas que no buscan desacreditar el trabajo de los posteadores sino que se limitan a tratar de solucionar los problemas y lo otro lo dejan como comentario secundario... espero que con esto me disculpes mi postura inicial. Gracias. Creo que rediseñaré algunas cosas y si esto funciona se los haré saber. |
Cita:
|
Cita:
Ya buscaste bien? Salud OS Edito: Hablar de bugs requiere de algo mas que no encontrar una solución a tu problema. |
Cita:
Entonces si no está ausente, no está funcionando como debe ser. ;) P.D. El vendedor estrella de Delphi Studio en México me dijo alguna vez: No creas todo lo que dice la cajita. A lo cual el mismo en esas sesiones se dio cuenta que su comentario no le daba más valor a su producto si no que también abarcaba los bugs no mencionados. Saludos. |
"Siempre hay mas de 1 forma de hacer las cosas y siempre hay una mejor forma de hacerlas"
PD. Estas pidiendo ayuda y a todos los estas bateando a lo masacre. |
Cita:
Sorry, se que a algunos les molesta pero me pagan por esto (y ahora que lo pienso, si no les comparto mi sueldo, creo que es injusto que me den una solución). Esa es mi postura, sorry. Me exigen solución a ese problema en especial y esa solución es la que busco. Gracias por comprender. |
Cita:
Cita:
Yo no se porque el comentario ironico que haces sobre ese "vendedor estrella", en fin, parece que sigues tomando las cosas muy a pecho. Ni modo, asi es esto. |
Te digo que soy malo para los sarcasmos y en este caso lo del vendedor estrella no era un sarcasmo.
Mira, veámoslo de esta manera... no se trata de reprogramar todo ¿crees que el problema específico de memoria pueda ser solucionado? (esto como lo dije antes, no depende realmente de la memoria física de la PC. Quiero aclarar que Delphi me gusta demasiado, más que cualquier otro lenguaje, pero estoy consciente de que pueda tener bugs (y vaya que los ha tenido). Pero hasta no saber si este es bug o no, no puedo retirarme de la solución. Saludos egostar. P.D. Espero no estarme haciendo acreedor a un baneo... espero no estar violando guías de estilo o cosas así. Eso será aceptado si alguien me llama la atención |
Hono a quien honor merece
Egostar, ese artículo de codegear me sirve bastante, me dio algunas ideas.
Gracias. Cita:
|
La franja horaria es GMT +2. Ahora son las 09:27:12. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi