FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Liberar componentes de la memoria
Hola ..debo revisar el codigo de un sistema que funciona pero debes en cuando tira errores de acceso a memoria , el clasico FFFFFFFF etc...
asumo que no debe estar liberando correctamente los componentes ,tanto forms , querys , etc.. La pregunta seria ..donde (en que evento) y como liberar eficientemente los componentes de la memoria , ...cuando se sale del from que los usa (onclose? destroy ?), es necesario hacer el close y el free ? sobre todo de las Querys o lo hace solo el delphi ? Lo mismo con los forms , ya que la creacion se va concatenando..(un form va creando uno o varios y asi sucesivamente) y creo que ahi se descontrola,al ejecutarse varias veces lo mismo ... por ej. en cada boton que llama a otro form hace el Application.CreateForm y el free si vuelve a presionar el boton hace lo mismo.... estimo que no es lo mejor..no? saludos Ingel |
#2
|
||||
|
||||
En un principio en el OnClose del Formulario pones
y no te tiene porque dar problemas. Un Saludo.
__________________
Guía de Estilo de los Foros Cita:
|
#3
|
|||
|
|||
y las querys ?
debo hacer el free al salir del form o close o ninguno?
GRACIAS |
#4
|
||||
|
||||
Cita:
El lugar donde liberarlos depende; La idea es que la visibilidad sea la mínima posible; A parte de eso, el evento OnDestroy es un buen lugar...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#5
|
||||
|
||||
Cita:
Me explico. Todos aquellos objetos que pueden pertenecer a otro objeto (formalmente los derivados de TComponent) son automáticamente liberados por su propietario (owner) cuando este se destruye. Así, si creamos un botón de la siguiente forma:
Estableciendo Form1 como su propietario, la memoria del botón será liberada al destruirse form1. Si a su vez Form1 pertenece al objeto Application, tanto este como el botón serán liberados automáticamente al terminar la aplicación... etc. Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#6
|
|||
|
|||
entonces..
en el proyecto hay una unit con todas las funciones comunes (uUtiles) varias de las cuales crean TQuerys en el var
var QTmp : TQuery; y luego QTmp:= TQuery.Create(Application); para luego conectarse a la DB y consultar o hacer un update por ejemplo.. Estas querys se liberan al liberar el form uUtiles ? (lo que se hace al cerrar la aplicacion) con lo cual se estarian creando cientos de querys sin liberar... o se libera cuando devuelve la llamada que le hizo algun form ? GRACIAS .. |
#7
|
||||
|
||||
Cita:
// Saludos pd: traducción de términos con dedicatoria a jachguate |
#8
|
||||
|
||||
Cita:
Si no los estas liberando, al ser propiedad de Application, se liberarán hasta le final de la ejecución, cosa que no me parece adecuada para la mayoría de los casos. En todo caso, quien sabe lo que pretende con esto y las necesidades específicas del programa sos vos, o al menos debieras saberlo.. En general es conveniente liberar la memoria tan pronto como el objeto deje de usarse. Así, si una función devuelve un TQuery, lo ideal sería algo como:
Cita:
¿hay algo malo en mi forma de traducir los términos?
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#9
|
||||
|
||||
Cita:
------------------- Normalmente no es buena idea hacer funciones que regresen objetos creados por ellas mismas precisamente porque es difícil dar seguimiento a cuando deben destruirse. Sin embargo, si esto es absolutamente necesario yo optaría por el uso de interfaces para que la liberación de memoria sea automática. La idea sería algo así:
La interfaz IQueryHolder simplemente mantiene una referencia a un objeto Query. La clase TQueryHolder implementa esta interfaz. Dado que desciende de TInterfacedObject, su destructor será llamado en cuanto se pierda la última referencia a la interfaz y este destructor se encarga de liberar al objeto Query. Para usar esta interfaz, la función UnQuery descrita por jachguate se debe modificar así:
Y para usar el resultado se haría así:
Como dije antes, Sin importar dónde esté declarada la variable QueryHolder, el objeto Query que contiene se liberará en cuanto se pierda la última referencia. // Saludos |
#10
|
||||
|
||||
Cita:
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#11
|
||||
|
||||
Cita:
Cita:
Cita:
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#12
|
||||
|
||||
Los puristas dicen que las interfaces no se hicieron para implementar un recolector de basura. Pero como a mi esto me tiene sin cuidado se puede incluso ir más lejos. En lugar del QueryHolder se hace una interfaz que "publique" los métodos y propiedades principales del objeto Query:
Y se usaría simplemente así:
De esta manera, el código que use lo devuelto por funciones como UnQuery se ve igual que si se hubiera usado un TQuery directamente. // Saludos |
|
|
|