Manual de TObjectList

[santiago14]

Buenas, estoy tratando de manejar unos punteros (listas que le dicen), veo que lo mas adecuado es TObjectList pero no encuentro algún buen manual para ayudarme. He buscado en la ayuda de Delphi y se entiende pero no hay demasiados ejemplos y cosas así.
¿Alguien conoce un manual por ahí?

Gracias, Saludos.

Santiago.

[Casimiro Notevi]

Hola, exactamente ¿qué buscas?, punteros y listas son cosas distintas (me ha salido con rima :))

[ecfisa]

Hola Santiago.

Te pongo unos enlaces que creo te van a servir:

Objetos auxiliares I (http://www.sjover.com/articulos/ObjetosAux_I.pdf)
Objetos auxiliares II (http://www.sjover.com/articulos/ObjetosAux_II.pdf)
Objetos auxiliares III (http://www.sjover.com/articulos/ObjetosAux_III.pdf)
Objetos auxiliares IV (http://www.sjover.com/articulos/ObjetosAux_IV.pdf)
Objetos auxiliares V (http://www.sjover.com/articulos/ObjetosAux_V.pdf)
Objetos auxiliares VI (http://www.sjover.com/articulos/ObjetosAux_VI.pdf)
Objetos auxiliares VII (http://sjover.com/articulos/ObjetosAux_yVII.pdf)


Saludos.

[roman]

Buenas, estoy tratando de manejar unos punteros (listas que le dicen), veo que lo mas adecuado es TObjectList pero no encuentro algún buen manual para ayudarme. He buscado en la ayuda de Delphi y se entiende pero no hay demasiados ejemplos y cosas así.


Tampoco es que haya mucha ciencia (*) en usar un TObjectList, de manera que, como apunta Casimiro, sería mejor que relataras qué necesidad específica quieres.

------

(*) Digo esto porque las listas en delphi son bastante fáciles de usar con métodos para insertar, borrar, buscar, etc. No como las listas enlazadas en que te debes preocupar por cómo asignar los apuntadores para las operaciones básicas.

// Saludos

[santiago14]

Hola, exactamente ¿qué buscas?, punteros y listas son cosas distintas (me ha salido con rima :))

Tengo que hacer un módulo de logística, es decir, en la Administración se matan vendiendo todo lo que tienen (y lo que no tienen), esas "ventas" luego se deben mandar a un remito para que se suban a un camión y la mercadería llegue a destino.
En esto de la generación de los remitos tenemos:
1) Varios remitos, uno por cliente al que se le vendió algo,
2) Un remito general, con los acumulados de los remitos particulares; esto es importante a la hora de llenar el camión y para control.
3) La "hoja de ruta" del camión, una serie de datos para saber que camión va, con que choferes, destino, fecha de salida, de llegada, etc.

Bien, esta funcionalidad es algo así como un formulario donde aparecen las ventas que ya se hicieron y el encargado del depósito "arma" la hoja de ruta con todos los remitos que considere pertinentes.
Como los remitos pueden ser parciales de las ventas (se vendieron 1000 kg. de papas, pero en este envío te llevamos solamente 250 kg) es que los detalles de los remitos son modificables antes de la generación, allí aparece el asunto del TObjectList.
Esta gente debe poder jugar con los remitos/ventas, sacarlos, ponerlos, modificarlos (mas renglones, menos renglones, en fin...) y la manera mas sencilla que imaginé es la de tener unos "punteros", "listas" o algo similar para hacer todas estas tareas y otras que no mencioné.
TObjectList tiene una buena tanda de métodos y propiedades que me servirían de mucho para armar unas clases que ya tengo en mente que relacione a esos objetos con las grillas y las impresiones que tengo que hacer.
Bueno, se que no he sido claro, pero la cosa es medio complicada.

Gracias por los aportes, voy a revisar los enlaces que me mandaron a como van.

Saludos, Santiago.

[santiago14]

Bueno, una de las cosas que me causaba malestar era que, tenía dos TStringList, y necesitaba que se copiaran (tener dos iguales) y, por alguna razón la cosa no salía bien. Hacía:
stringList1:=stringList2;
Luego quería modificar mis cosas en stringList1 y resulta que aparecían cosas de stringList2, bueno esto es lógico, estamos hablando de referencias de memoria (1° año de universidad, hace tanto ya...) Bien, leyendo esos apuntes que me recomendó ecfisa encontré el método "Assign", que parece que resuelve la cosa de mejor manera.
Bien, ya es tarde en la Argentina y estuve peleando toda la tarde con el asunto, así que me voy a la camita, a disfrutar de la primera final de la Libertadores (¡¡vamos Boquita!!) y mañana me pongo en campaña a modificar los métodos de mi clase a ver que onda. Les comento, y si resulta bien, publico aquí la pequeña clase que hice.

Saludos, Santiago.

[Casimiro Notevi]

Yo lo haría directamente en la base de datos, un "remito" será algo así como un "albarán de entrega", sólo has de añadir un campo más: "entregado".
Si tienes el campo "Cantidad", sólo has de poner en "entregado" lo que se le envía al cliente. Cuando "Cantidad" y "Entregado" son iguales entonces se pone el campo "Estado" a Finalizado, por ejemplo.
El "Estado" es un campo que puede ser
1.Por confirmar
2.Confirmado
3.Entregado parcial
4.Entregado total

Es sólo un ejemplo, depende de lo que necesites.

Pero todo ese proceso lo haría en la base de datos, ¿qué haces con esas listas?, si luego tienes que guardarlas en la BD, pues lo haces directamente.

[Delphius]

Yo lo haría directamente en la base de datos, un "remito" será algo así como un "albarán de entrega", sólo has de añadir un campo más: "entregado".
Si tienes el campo "Cantidad", sólo has de poner en "entregado" lo que se le envía al cliente. Cuando "Cantidad" y "Entregado" son iguales entonces se pone el campo "Estado" a Finalizado, por ejemplo.
El "Estado" es un campo que puede ser
1.Por confirmar
2.Confirmado
3.Entregado parcial
4.Entregado total

Es sólo un ejemplo, depende de lo que necesites.

Pero todo ese proceso lo haría en la base de datos, ¿qué haces con esas listas?, si luego tienes que guardarlas en la BD, pues lo haces directamente.
Creo y me parece Casimiro que a lo que apunta santiago14, es que cuenta con su propio juego de clases y necesita que una (al menos) de ellas tenga o mantenga referencias a una lista, grupo, o colección de otras clases (mejor dicho, instancias de una o más clases).
Para ello no hay demasiadas opciones, y todas se resumen a que la clase en cuestión disponga de un atributo que le permita llevar listas... puede utilizarse TObjectList, TList o cualquier otro tipo de xList; cada uno tiene sus utilidades y facilidades.

TMiClase = class
private
FListaClases2: TObjectList;
public
procedure Agregar(Clase2: TMiClase2);
....
end;

La otra posibilidad, si se puede y/o considera oportuna, es heredar de alguna de las XList y disponer en éstas de los métodos de interés.

Luego, estas clases se harán persistentes (al menos las que se necesiten o consideren) en la base de datos. Es muy útil tener este grado de abstracción hacia el pensamiento OO y no quedarse en el enfoque RAD y sobre todo si se emplea mucho el data-ware sin mediar algún control de por medio; ya que con esto se está implementando una buena biblioteca de dominio que luego puede ser volcada sin demasiado trabajo en otros casos en que requiera del mismo o similar contexto.
Al diseñar la clases se está llevando consigo la combinación procesos y datos.
Para este enfoque es muy útil recurrir a un framework de persistencia, salvo que el diseño sea tan simple y que permita hacer un mapping O-R de forma relativamente sencilla y no tan aparatosa.

Yo trabajo con ese enfoque: clases dominios, que luego van a un mini framework de persistencia que se encarga de guardar, actualizar, o recuperar hacia/desde la base de datos. NO uso data-ware, o de alguna forma directa hacia la DB. Me parece más "limpio" y seguro.

Saludos,